> ## Content Index > Fetch the complete content index at: https://wi.senterprises.com/llms.txt > Use this file to discover other available public pages before exploring further. # Alignment Is Not Distributed With the Document - URL: https://wi.senterprises.com/articles/alignment-is-not-distributed-with-the-document/ - Published: 2026-10-02T08:00:00.000Z - Updated: 2026-11-06T03:10:59.000Z - Description: An enterprise data strategy does not spread from where it is written; it is taken up, one decision maker and one business unit at a time, through standards each unit can see the point of. And the data it is aligning loses value from the day it is collected, so the work belongs on the data the… - Author: Jeffrey Shabel - Tags: Enterprise Data Strategy, Enterprise Data Strategy Formulation & Vision, 2026, October 2026, 2026-W40, AI: Contextual, Reference Data & Metadata Strategy at Enterprise Scale, Integration of Enterprise Data Strategy with Other Business Strategies, #wi-art_01KVZKVTFN7PGVQPCT2W1S882G *Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary* Where a data strategy is written down has never seemed to me to matter. It can be a document of its own or a chapter of the business strategy. The test is whether the business reads it and builds it into how it runs. So were the strategies that do steer decisions the standalone kind or the embedded kind? That is the wrong question: > Strategies don’t drive decisions. People drive decisions. People who use the strategy to justify or support those decisions. Therefore it’s not the placement nor the ownership of the strategy that matters, it’s which decision makers support it and integrate it into their decision making process. > > If you want to think of a legal analogy, it doesn’t matter if the law being enforced is at the city, county, state or federal level—or if it’s a regulation—it matters entirely that someone elects to apply and enforce it and how they interpret it to have been violated. The usual question about a data strategy at scale is how to keep it aligned. Aligned with the business strategy, that is, and with whatever transformation programme is carrying it, in every unit of a large organisation. The usual answer is architectural: write the document well, place it high enough, and govern it centrally or federate it carefully. Alignment will then spread outward from where it was written. I do not think alignment spreads. I think it is recruited, one decision maker at a time. The units it is recruited in receive the same document as different instructions. The standards that carry it have to make sense to each of them. And the data it aligns is worth a little less every day. Whether a strategy gets its money at all is a separate question, taken up in the earlier piece on this line, ["Does Being Named the Foundation Get a Master Data Programme Funded?"](https://wi.senterprises.com/articles/the-strategy-document-is-newer-than-the-argument-it-settles/) This piece starts after the signatures. ## What the literature already concedes The literature says much of this already. It just stops short of who does the work. Henderson and Venkatraman's alignment model divides the territory into four domains of strategic choice and rests alignment on fit and integration between them [\[1\]](#ref-1). A manager they interviewed put it better than the model. It is best viewed, he said, as "a 'journey and not as an event'" [\[1\]](#ref-1). Quite so, but the model never says who walks. Mintzberg and Waters had answered that in 1985, without meaning to answer it for data. The strategies organisations actually follow sit on a line between the deliberate and the emergent, and the kinds they found along it include "planned", "umbrella", "consensus" and "imposed" [\[2\]](#ref-2). Roughly: what was intended at one end, what emerged at the other. A data strategy is written as if it were planned and lands as if it were imposed, and what the units actually do with it is the emergent part nobody wrote. The execution research adds numbers. Donald Sull, Rebecca Homkes and Charles Sull surveyed some 7,600 managers in 262 companies. They found that 84 per cent could rely on their bosses or their direct reports. Only 9 per cent could rely on colleagues in other functions and units consistently; about half could most of the time. Thirty per cent named failure to coordinate across units as the biggest obstacle to executing strategy [\[3\]](#ref-3) [\[4\]](#ref-4). The vertical line through a unit carries a strategy well. The horizontal line between units carries it far less reliably. A data strategy is a horizontal thing. The best technical answer is federation. Zhamak Dehghani's federated computational governance leaves each domain to model its own data and decides globally only what joins domains, under a group made up of the domains' own representatives, who must keep "an equilibrium between centralization and decentralization" [\[5\]](#ref-5). I think that is the right architecture for most large estates. Its platform can enforce what a machine can check; it cannot make a unit use the governed meaning of a field. No architecture does. ## Placement draws the map; somebody else enforces it The legal analogy has a studied original. Michael Lipsky's work on street-level bureaucracy, the caseworkers, police and teachers who apply policy one person at a time, is summarised by its publisher in two passages: "the difference between government policy in theory and policy in practice can be substantial and troubling", and "the cumulative effect of street-level decisions made on the basis of routines and simplifications about clients can reroute the intended direction of policy" [\[6\]](#ref-6). A data strategy is enforced at the street level too. Somebody decides, record by record and report by report, whether the governed definition gets used. The level the strategy was written at does not decide that. The person at the counter does. Placement still buys something, though not the people. What does it buy, then? Ground to stand on: > It establishes defined and defensible spheres of influence. However, those have little bearing unless the Enterprise respects them. This is a constant battle in most companies with which I've interacted as various groups within the Enterprise engage in disputes regarding territory. Further, it can be used as a precedent to move into a vacuum. The word that matters is *defensible*. A sphere the strategy draws does not enforce itself. But it can be argued for. When two groups dispute who owns the definition of a supplier, the one whose authority is written into an approved strategy has a document to point to. That is not nothing, but it is not alignment either. It is a stronger position from which to argue for alignment, and somebody has to argue it, in a meeting, against somebody who would rather not. Placement is also precedent. Asking forgiveness rather than permission has a quieter cousin in governance: something beats nothing. A definition or naming rule that works in one domain can be carried into a neighbour that has no rule at all, on the modest grounds that it is a place to start. That is one way a standard reaches a place that had none. Federation, read this way, is a structure for recruiting people, not a substitute for it. Dehghani's governing group is made of the domains' own representatives [\[5\]](#ref-5). The global rules are only as enforceable as those people make them at home. The architecture puts the right people in the room. It cannot make them carry the result back out. ## The same document arrives as different instructions The sources show that people carry a strategy but not where, inside an enterprise, the carrying breaks; from here the warrant is my own record, and it is pattern, not law. It breaks first on the differences between units that nobody writes into the strategy, because they are not about data. How much operational overhead does the unit already carry? How trained and experienced are its people, and how is their day already divided? How thinly is it staffed, and what else is pulling at it? How much regulation was it carrying before anyone mentioned data? Why does a strategy that worked in one unit go wrong in the next? Because the receiving groups are not alike: > Lifting and shifting a Data Strategy designed and implemented by the Data Governance group to the Project Management group is likely to go significantly better than trying to do the same thing with the Manufacturing group as the target. One of the groups at least shares the vocabulary and general concepts—to the other it’s completely foreign (and, yes, generalizations, not every group, etc etc etc). > > The point is when implementing something as broad reaching as a Data Strategy across the entire organization, it’s essential to do everything possible to meet the other business groups where they’re at and make sure there is time allocated for training and daily use in the updated schedules, otherwise things will be very expensive and very disruptive. That is a generalisation, and I mean it as one: if the line between units is unreliable in general [\[3\]](#ref-3) [\[4\]](#ref-4), it is likely to be worse where the units do not share the words. So translation is the first cost of scaling. It is a cost in hours: hours to learn the terms, then hours to use them every day, inside schedules that were already full. A strategy that does not put those hours into the revised schedules has not been scaled. It has been announced. The usual response to a unit that ignores the strategy is to send it again, more firmly. When I inherit a strategy nobody follows, I start somewhere other than the document: > Step one is find out why it’s not being followed—before you even spend time reading the strategy. If the strategy demands or requires something the business cannot or will not provide, the problem isn’t with the business because the business was operating sufficiently well to garner enough growth to have the Data Strategy conversation. I said that of the business as a whole, and it holds for a single unit as well: something it does works, and the strategy is the newer and less tested of the two. Asking why first means hearing the unit's reasons before the document has framed them as resistance. What follows is a partnership and a negotiation, not a decree. The one exception is the regulator. When the regulators arrive, the negotiation is over for everybody. There is a sequencing point underneath this that the alignment sources cited here do not address. The gap between the strategy everyone agreed and the one that got funded is not special to data. It is the ordinary gap between what a business can afford and what it would do without limits, and data strategy sits low on the list. A business needs slack in time, money and people to fund governance first. Only then can it afford a data Strategy with a capital S. My expectation, and it is an expectation rather than a finding, is that the units furthest from a strategy's home are often the ones with least slack. If so, the strategy reaches them last and finds them least able to absorb it. ## Who actually carries it: signatories, and the middle If placement does not recruit the people who will enforce a strategy, what does? The first question at approval is whether there is anyone to recruit. The early test is a gap, not a feeling. Compare how much of the organisation the strategy reaches with how many of the people it reaches signed it. The more of the directly affected leaders who signed, the better its chances. A strategy that covers the whole enterprise, signed by one function, is one most of its subjects have only read about. After that, everything turns on whether the people at the end of the line turn it on, feed it and use it. The best system a governance group could build is worth nothing if they do not. One role keeps breaking: the business data steward whose job includes stewardship, as against the steward whose job is stewardship. The first kind is a constant problem. A strategy that assumes the second kind will be carried out on Friday afternoons. Signatures are the formal half. The informal half is the layer underneath them. What is the one sign that a strategy will be carried out rather than merely approved? > How broad the ‘buy-in’ is at the middle manager level. The smaller the group and the more interested they are in trying to make it work—and this goes for all Enterprise-wide projects—the more likely it is to achieve its ends. This is why expanding it to the entirety of the Enterprise carries such risk: the Enterprise is definitionally not small. > > That’s why the middle managers are so important to get on board. They’re a small enough group that they can be addressed and engaged with directly while being broadly distributed throughout the entire Enterprise. > > When it comes to Data Strategy, or any comprehensive restrictions placed upon the Enterprise as a whole, it’s essential to get enthusiastic support from those who will be the ones enforcing and implementing it at the user level. That is the answer to what looks like a contradiction. The enterprise is too big to engage directly; the middle managers are few enough to engage and spread widely enough to cover it. No other layer is both. When they are not on board, that is where the strategy quietly stops. The research supports involving this layer, and it presses on the word I chose for what they must give. Wooldridge and Floyd studied middle managers in twenty organisations. Involving them in forming strategy went with better performance. Consensus among them, which they defined as understanding of the strategy and commitment to it, went with involvement but not with performance [\[7\]](#ref-7). So is involvement in forming a strategy a stand-in for the enthusiasm I asked for, or something else? > The amount of involvement in forming a strategy is a reasonable approximation for enthusiasm. It also has the side-benefit of also documenting investment. Perhaps a better way of putting it would be 'level of investment' instead of 'level of enthusiasm,' since enthusiasm is an emotional driver of action while investment is a status driver of action. > > The core point is there needs to be some higher than 'normal' or 'ambivalent' level of impetus to take action in support of the project. The absence of motivation to take action to defend, support or enact the project is what kills it, so whether it's investment, enthusiasm or something else, it's the action that's truly the determining factor. The better measure, then, is less how warmly a manager feels about the strategy than how much of their own standing they have put into it, and whether that turns into action. Involvement in forming a strategy is something a manager can be seen to have done, so it records a stake where a measure of commitment records only an attitude. That is where the study and the rule meet: in that sample, consensus, understanding and commitment together, did not go with performance, and involvement did [\[7\]](#ref-7). The working rule follows. The middle managers who will enforce a data strategy need a hand in forming it, early, while their investment can still be made visible. Support gathered once it is written has not yet shown a stake, and counts when it turns into action. The final test is action. A strategy survives when someone in the middle will defend it, support it or carry it out when that costs them something, and it dies of ambivalence. A later study by the same pair, of 259 middle managers, found that those in boundary-spanning sub-units reported more strategic influence activity. The authors trace it to middle managers' ability to mediate between internal and external environments. Firm performance went with more uniform downward influence from the middle, and with more varied upward influence [\[8\]](#ref-8). On my reading, not the study's, that fits the reason for choosing this layer. A layer spread evenly through the enterprise can carry a strategy down evenly. A few willing managers carry it to some units and not others. ## Standard or straitjacket Most days the middle does not carry the strategy. It carries the standards the strategy spawns: naming rules, definitions, mandatory fields, approved tools, review gates. That is where a unit decides whether the strategy is a help or a cost. Where does an enterprise standard become an enterprise straitjacket? > It’s when required features are prevented or substantially altered in order to comply with ‘standards’ that they become a straitjacket. Refactoring the way the company or business works and produces value for their customers solely in order to comply with arbitrary ‘standards’ is when things start to spiral. > > Note I said ‘arbitrary.’ Regulatory, security or tool-related requirements, while frequently onerous and disruptive, primarily represent a changing business environment and not arbitrary architectural, coding or naming standards—those normally come into play when groups attempt to ‘bring into alignment’ areas outside of their immediate purview. Arbitrary is the operative word. I keep a list of what standards are for, and it works as a test. A standard earns its place if it heads off a known naming, structure or architecture trap. Or if it lets one group read another's work when something breaks, or lets people move to where the work is. Or if it makes logging and error handling uniform, makes a system easier to use or document, is required for compliance or security, or reflects an industry best practice. A standard that serves none of those is probably arbitrary and "could be causing more problems than it solves." The list need not be complete. Its value is that a standard has to name its purpose before it is imposed on a unit that did not ask for it. That is the moment straitjackets are made. Who does an arbitrary standard hurt most? Often the team that solved the problem first. The pattern goes like this: > Oh, yeah. That's simple: if the business unit followed the standard, they'd lose their entire development team. Once you have a development team that's worked together for years and established their own standards, forcing them to change for no reason other than compliance with other teams that are just now catching up is a good way to produce mass resignations. That is the straitjacket in its plainest form: groups that are only now catching up "bring into alignment" an area outside their purview, and the area they reach is the one with the oldest and most tested standards. The team has a stake in those standards, the same investment the middle managers needed. A legacy team consulted early is a stake made visible; a legacy team overruled is a stake turned against the strategy. What should a standards board do with a team like that? > If you've got 'legacy' teams who have been solving these kinds of problems for years or decades, it behooves the Standards Board to consult them and try to incorporate their standards as the core of the newly established Enterprise standards. They've already been dealing with the problems that standards are normally enacted to solve, so it makes sense to try to leverage their experience. Else they might just depart as a block--if that happens, you had better already have planned a contingency for their replacement. That is finding out why first, done before the standard is written rather than after it has failed. The last item needs care. Best-practice documents are also a consultancy deliverable that does not survive contact with the business. Best practices do establish standards, but each has to be weighed for whether it applies to this business. Some businesses are non-standard by nature, with best practices of their own. How can best practice be both the reason for a standard and the reason one fails? > The core reason most companies make the effort to adopt 'best practices' is their direct applicability to the business. In the absence of that, a 'best practice' that brings no value supports no project. Think of an entire encyclopedia wherein only certain volumes are of use to the business. It makes no sense for the company to attempt to justify a project based upon a volume that has no intersection with the needs of the business. That sounds contrarian in a room where a framework has just been presented. It is what one of the most widely used frameworks says about itself. The NIST Cybersecurity Framework "does not prescribe how outcomes should be achieved". It says that "by necessity, the way organizations implement the CSF will vary". Its organisational profile exists to "understand, tailor, assess, prioritize, and communicate" its outcomes against an organisation's own mission [\[9\]](#ref-9). A framework that tells its readers to test applicability is badly served by a programme that skips the test. The volumes that do not intersect with the business are not a lower priority. They are not part of its standard at all. Put in order, the test checks the exception first. Whatever a regulator, security or the tools themselves require is often onerous, but it is not arbitrary, and it is complied with. Everything else has to name a purpose, apply to this business and this unit, and leave the unit's required features intact. ![A decision flow. First: is it a regulatory, security or tool requirement? If so, comply. Then: does it name a purpose, apply to this unit, and leave required features intact? Failures exit to arbitrary, not this unit’s standard, straitjacket.](https://wi.senterprises.com/assets/diagrams/FIG003_EDS_Standard_Or_Straitjacket_v1_0.png) Figure 1: A regulatory, security or tool requirement is checked first and complied with even when it is onerous; anything else reaches a unit as a standard only if it names a purpose, applies to that unit and leaves its required features intact. **Standard or straitjacket: the questions a standard should pass before it is imposed on a business unit** A decision flow. A key across the top reads: **How to read this** \[n\] — a source cited in the article; (practitioner) — the operating experience quoted or restated in the article; (this publication’s reading) — the article’s own argument; Amber outline — the only route that ends in a standard. A sequence of questions, not a measurement: nothing here is counted or ranked. Four questions run down the left: **1\. Is it a regulatory, security or tool requirement?** (Such requirements reflect a changing business environment; they are not arbitrary standards (practitioner)); **2\. Does it name a purpose?** (Heading off a known naming, structure or architecture trap; letting one group read another’s work when something breaks; letting people move to where the work is; uniform logging and error handling; ease of use; ease of documentation; compliance; security; an industry best practice (practitioner)); **3\. Does it apply to this business, and to this unit?** (Every best practice weighed for applicability; even the NIST framework asks to be tailored [\[9\]](#ref-9)); **4\. Does complying prevent or substantially alter a required feature, or make the unit rebuild how it produces value?** (The line between a standard and a straitjacket (practitioner)). Question 1 leads down to question 2 on **No**; questions 2 and 3 lead down to the next question on **Yes**. Each question has an exit to the right. From question 1, **Yes** leads to **Onerous is not arbitrary: comply** (Often onerous and disruptive, but not an arbitrary standard (practitioner)). From question 2, **No** leads to **Probably arbitrary** (Could be causing more problems than it solves (practitioner)). From question 3, **No** leads to **Not part of this unit’s standard** (A volume of the encyclopedia with no intersection with the business supports no project and no standard (practitioner)). From question 4, **Yes** leads to **A straitjacket** (Where things start to spiral (practitioner)). From question 4, **No** leads down to the one card outlined in amber: **A standard** (Introduced incrementally, at the pace the unit can learn, with training and daily-use time in its schedules (practitioner)). The closing band: **Alignment is recruited, not distributed.** A standard that does not pass these tests for the unit receiving it is where a strategy loses that unit. (this publication’s reading) Pace matters as much as selection. Best-practice documents and industry-standard implementations that make the business rebuild its processes fail for a reason that deserves respect. The business reached the point of needing a strategy without one. Moving it off what has demonstrably worked meets an inertia that is entirely rational. The better course is to pivot incrementally, as slowly as the business can afford, so that end users are trained and, more to the point, on board. A big switchover can work. It carries a great deal of risk. The risk is not abstract. Hershey's new order and distribution systems went live in 1999 just as the Halloween orders arrived. The company had to tell Wall Street analysts it would miss some $100 million of deliveries [\[10\]](#ref-10). That was not a data strategy, and one case proves nothing about rates. But it shows what a business looks like when it has stopped trusting its old way and not yet learned its new one. A data strategy imposed all at once on a unit with no slack produces the same condition on a smaller scale. ## Align the data that still has value One question is left: which data should each unit be asked to align? The data it decides with now, not its history, and the reason is a clock that runs under every strategy. All data loses value from the day it is collected. If even last quarter's figures can steer a decision wrong, older ones usually steer it wrong further. Sometimes old data is still the best evidence you have. It is worth less than it was, and you are using it anyway because it still has the most available value. I was asked to sign a sentence calling data an asset only at what it cost. I declined. This is the sentence I would sign: > Data is an asset only insofar as it provides accurate information on which to make business decisions. This is the main reason why *all* data depreciates: the further in the past the data, the less value it provides to current business decisions. Value lives in current decisions. That is the position the companion piece on measuring master data's value takes from the other side, in [*An Asset Is Not a Return*](https://wi.senterprises.com/articles/mdm-asset-is-not-a-return/): value comes from use, and a figure for what data is worth is not a return on keeping it. Moody and Walsh put both forces in their laws of information in 1999\. The second law is "The Value of Information Increases With Use". The third is "Information is Perishable": "like most other assets, the value of information tends to depreciate over time" [\[11\]](#ref-11). The two do not conflict. Use raises value; time lowers it. Data-quality researchers have since built metrics for how current a stored value is likely to be [\[12\]](#ref-12). The strongest objection is that old data is sometimes the better guide. Figures from the last downturn may steer the next one better than last quarter's boom. But depreciation compares a datum with itself over time, not old data with new. My quarter example was an argument from the stronger case. If even the newest figures can mislead because conditions outside the business outweighed them, older ones have no claim to do better as a rule. The downturn figures are worth less than when they were collected. They may still be the best evidence available. Then you use them, knowing what you are paying for. The decay is not only stale addresses. It is meaning, and it reaches all data, not just master and reference data. The further a record is from its collection, the less the enterprise remembers about how it was collected. That context is much harder to store than the value. A capital-project flag can mean one thing in a record from 1927, another in 1977 and a third in 2027, under the same field name. A good library of definitions would slow the loss, often by a great deal, but linguistic drift means it cannot stop it. The loss need not be significant. Like entropy, it is simply everywhere. Even reference data built to be stable has done it. The two-letter country code CS meant Czechoslovakia, and was later reassigned to Serbia and Montenegro. In 2003 the Internet Architecture Board wrote to ISO to object, because identifiers carrying the old code would now appear to refer "to a different object in Serbia and Montenegro" [\[13\]](#ref-13). A country code is not a customer field, and I offer it as an analogy, not a measurement. But if the most deliberately stable codes in the world can change meaning under a stored value, a field an enterprise argues over can too. Some old data cannot even be fixed. My name for data that no longer serves the business but still has to be maintained is a time share: something owned that keeps costing to hold, in upkeep spent protecting, defending and distributing data that is questionable at best and misleading at worst. It has the time share's trap too. Once the business relies on data, even bad data, correcting it disrupts forecasts already in use. It can also mean restating regulatory reports already filed. That second risk is written into the rules. A bank's supervisor may require an amended filing for significant errors in "how the reporting bank classified or categorized items in the reports, i.e., on what line of the report an item has been reported" [\[15\]](#ref-15). A definition corrected in the master data can move a line in a report somebody has already signed. Here is what that means for scaling. A strategy that asks every unit to align its history to the enterprise definitions is asking each of them to pay for the part of its holdings with the least value left. It is also asking them to take on the restatement risk. Much of that history is already thinned by retention rules, which keep identifiable personal data "for no longer than is necessary" [\[14\]](#ref-14), leaving rollups and metadata behind. A strategy that asks every unit to align the data it decides with now is asking for the part that still carries value. Scale by aligning that. I rank the work this way: "The core value MDM provides is to direct business operations; historical tracking comes with it." Accurate history comes as a by-product of getting current operations right. It is not the reason to do the work, and not where the alignment effort should go first. ## What scales So here is where I land. A data strategy is aligned with the business strategy, across a whole enterprise, by local acts rather than one central one. It is aligned when somebody who decides things in a unit uses it to justify a decision. It is aligned when the unit's reasons for ignoring it were heard before it was resent. It is aligned when the people it binds signed it, when the middle managers who enforce it helped form it and will act for it, and when the steward who keeps it has the hours. It is aligned when each standard can name its purpose and its fit for that unit, and arrives at a pace the unit can learn. And it is aligned on the data the business uses now, because that is the data still worth aligning. None of that makes the document unimportant. Its placement draws defensible boundaries. A rule that works in one domain becomes a precedent for the next. Federation puts the right representatives in the room [\[5\]](#ref-5). But the document and the architecture are a map. A strategy takes hold at the counter, where somebody chooses to use it, or it does not take hold at all. The scaling problem is not writing a better map. It is recruiting enough of those people, fast enough, to decide with data that is still worth deciding on. ## References \[1\] John C. Henderson and N. Venkatraman, "Strategic Alignment: A Model for Organizational Transformation via Information Technology," MIT Center for Information Systems Research, CISR Working Paper No. 217, November 1990 (published in revised form in *IBM Systems Journal* 32(1), 1993, which was not read). Cited for the four domains of strategic choice, the two building blocks (strategic fit and functional integration), and the interviewed manager's "journey and not as an event". \[2\] Henry Mintzberg and James A. Waters, "Of Strategies, Deliberate and Emergent," *Strategic Management Journal* 6(3), July 1985, pp. 257-272\. Read at the abstract only. Cited for the deliberate-emergent continuum and the strategy types the abstract lists. \[3\] Donald Sull, Rebecca Homkes and Charles Sull, "Why Strategy Execution Unravels — and What to Do About It," *Harvard Business Review*, March 2015\. Paywalled; only the summary was read. The figures in the body are taken from the report at \[4\], not from the article itself. \[4\] John Kamensky, "What Does It Really Take to Get Things Done?", *Government Executive*, 13 March 2015\. A report of \[3\]; cited for the sample (7,600 managers in 262 companies in 30 industries) and the figures quoted in the body: 84 per cent relying on bosses or direct reports, 9 per cent consistently relying on colleagues in other functions and units, about half "most of the time", 30 per cent naming failure to coordinate across units. \[5\] Zhamak Dehghani, "Data Mesh Principles and Logical Architecture," martinfowler.com, 3 December 2020\. Cited for federated computational governance (domain-local decisions under global rules), the "equilibrium between centralization and decentralization", and the governance team "made of domains representatives". \[6\] Michael Lipsky, *Street-Level Bureaucracy: Dilemmas of the Individual in Public Services*, 30th anniversary expanded edition, Russell Sage Foundation, 2010 (first published 1980). The book was not read; cited for the two sentences quoted from the publisher's description. \[7\] Bill Wooldridge and Steven W. Floyd, "The strategy process, middle management involvement, and organizational performance," *Strategic Management Journal* 11(3), 1990, pp. 231-241\. Read at the abstract only. Cited for the study of middle managers in twenty organisations: involvement in forming strategy associated with improved performance; consensus (understanding and commitment) related to involvement but not to performance. \[8\] Steven W. Floyd and Bill Wooldridge, "Middle Management's Strategic Influence and Organizational Performance," *Journal of Management Studies* 34(3), 1997, pp. 465-485\. Read at the abstract only. Cited for the 259 middle managers, the higher strategic influence activity reported by those in boundary-spanning sub-units, the authors' attribution of that influence to middle managers' ability "to mediate between internal and external selection environments", and the association of firm performance with more uniform downward influence. The reading of the uniform-influence finding as support for choosing a widely distributed layer is the article's, not the study's. \[9\] National Institute of Standards and Technology, *The NIST Cybersecurity Framework (CSF) 2.0*, NIST CSWP 29, 26 February 2024\. Cited for the three passages quoted in the body (the CSF does not prescribe how outcomes are achieved; implementations will vary; Organizational Profiles used to tailor and prioritise). \[10\] Christopher Koch, "Hershey's Bittersweet Lesson," *CIO*, 15 November 2002\. A trade report of the primary, Hershey's own disclosure on a September 1999 analyst call (not read). Cited for the September 1999 disclosure to Wall Street analysts, the go-live as Halloween orders arrived and the "$100 million worth of Kisses and Jolly Ranchers" the company said it would not deliver. One case; cited as an illustration of switchover risk, not as evidence of a rate. \[11\] Daniel Moody and Peter Walsh, "Measuring the Value of Information: An Asset Valuation Approach," European Conference on Information Systems (ECIS '99), Copenhagen, 1999\. Read in a copy hosted by the University of Edinburgh. Cited for the second law ("The Value of Information Increases With Use") and the third ("Information is Perishable"), with its explanation quoted in the body. \[12\] Bernd Heinrich and Mathias Klier, "Metric-based data quality assessment — Developing and evaluating a probability-based currency metric," *Decision Support Systems* 72, 2015, pp. 82-96, doi:10.1016/j.dss.2015.02.009\. Read at the abstract only. Cited for the existence of metrics of data currency. \[13\] Internet Architecture Board (Leslie Daigle, Chair), "IAB comment on stability of ISO 3166 and other infrastructure standards," statement dated 24 September 2003, with a letter to the President of ISO dated 26 September 2003 (the statement was also sent to ICANN). Cited for the reassignment of the code CS from Czechoslovakia to Serbia and Montenegro and the phrase quoted in the body. \[14\] Regulation (EU) 2016/679 (General Data Protection Regulation), Article 5(1)(e), "storage limitation". Read in an unofficial consolidated text. Cited for the phrase quoted in the body. \[15\] Federal Financial Institutions Examination Council, *FFIEC 031 and FFIEC 041 Call Report Instruction Book Update*, September 2018, General Instructions, "Amended Reports". The current edition of the instructions was not opened. Cited for the supervisor's power to require an amended report for significant classification errors, quoted in the body.