Load-Bearing: Differentiator, Cost Centre, and the Question Neither Label Asks

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

Asked whether AI-enhanced master data management is a strategic differentiator rather than a cost centre, I did not take either side. My first two sentences were these:

Sure—it's a great way to burn a budget extremely quickly. AI is a tool, just like any other and it provides new abilities, just like all other specialized tools.

The sure is a concession, and the rest of the sentence is its price. Anyone may call AI-enhanced master data a differentiator; the word is free. What it commits the business to is a spend whose rate is set by how loosely the work is specified, on a process that may soon be impossible to switch off, and neither of those appears in the sentence that wins the budget. There is a sentence master data leaders are encouraged to say out loud, and it runs roughly like this: with AI in the platform, master data management stops being a cost centre and becomes a strategic differentiator. It is not a dishonest sentence. It gets budget, which is what a sentence in that position is for. But notice what the two labels have in common. Cost centre and differentiator sort the same investment on one feature: where its number sits in a ledger, and whether the line can be defended upward at the next planning round. Neither asks what the spending does to the business once it is inside a process that matters.

The feature I would sort on instead is whether the spending can be declined. A cost you can stop next month, at the price of a slower queue and one unhappy stakeholder, is a cost. A cost you cannot stop, because the process it runs is one the business can no longer suspend, is a dependency, and its number is set by somebody who does not work for you. That distinction can be operated, which is the only reason it is worth asserting: any process can be tested against it by asking what happens on the first of the month if the invoice is refused. The differentiator question has no test under it at all, and a label with no test under it is an argument nobody can lose.

What is being appealed to, when nothing has accumulated

Asked which piece of accepted wisdom about AI in master data platforms I would argue against, I declined to name one. The reason is that I do not know what that wisdom is: the practice is new enough that I find it hard to believe any has accumulated. What I said instead was this:

I'd just make the same arguments against that accepted wisdom as I would against any other set: it's a set of heuristics that have, at most, 80% 'generic' utility. They're guidelines, not rules and need to be considered for their applicability to any specific situation before being vigorously applied.

That is checkable, so it was checked. A search for accepted wisdom, best practice and lessons learned on AI in master data management, run on 21 August 2026, came back as vendor pages, vendor blogs and implementation-partner listicles.

A disclosure belongs here, before I assess anyone's material. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, and a licence sale we refer earns us a referral fee from the vendor. Beyond both, our services revenue depends on master data software being bought at all, so what I say about the claims made for it is said by people with a stake in the category. The vendor material I examine below belongs to other companies and was chosen because it is public and specific. Weigh my criticism above any praise.

The most substantial search result was a reference article from a major master data vendor, and it is a fair sample because it is one of the better ones: a five-step strategy sequence closing on the vendor's own AI component, its quoted authority the vendor's senior director of product marketing [1]. Its underlying argument, that AI readiness is a governance and quality problem before it is a model problem, is one I would sign. It is not the same artifact as a report from somebody who has run this for three years and can say where it went wrong.

The other category was forecast. The most quoted line predicts that "over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls" [2]. My quarrel is not with the analysis but with the job it is given, which is standing in for experience nobody has yet: a claim about 2027, published in 2025 beside a poll of webinar attendees who reported how they were investing rather than what they had got back.

Practice reports do exist, in ones and twos, for a reader willing to look in the literature instead of the marketing. MERAI, published in 2025, describes an entity-resolution pipeline that eight named authors built and ran on real deduplication and linkage projects inside a bank. They benchmarked it on datasets of up to 15.7 million records, where one widely used open-source library ran out of memory past two million, and applied it in production to as many as 33 million [10]. That is an attributable report from people who did the work, which the vendor material is not, so the sweeping form of what I said is already too strong. It is still not the artifact I described, and I should say why rather than let the concession pass. Read that paper looking for the part where it went wrong and the part is not there: the pipeline is reported as having handled every dataset in every project it was used on "without any failures" [10], no operating duration appears anywhere in it, and the limitations it discusses are those of Dedupe, Splink and Magellan rather than its own. Its future work is a feature-engineering improvement.

So the position has to be stated more carefully, and in its careful form it holds. Accounts of what somebody built, at what scale, against named alternatives, do exist in the literature, and they do not travel: what reaches a data leader is product copy and dated prediction. The exposure is not that a bad rule will be believed. It is that marketing will be taken for a rule at all, because at slide distance the two look the same. And the account of the failure, from somebody far enough in to have had one, is still not written down. A literature of successes is not experience; it is a portfolio, and the difference is exactly what a person planning this work would pay to read. That is why the fallback I gave, heuristics that are at most four-fifths generic, with the rest to be earned by checking whether they fit, is not an evasion. It is what remains when there is no body of experience to appeal to, and it is the standing of everything I am about to say.

A published result, held up against the argument

The case against the differentiator label goes further than the ledger. The choice that label implies is one I refuse:

That's a false choice because there's no AI capability that allows a company with an unlimited budget to do something new. AI doesn't have sufficient imaginative capacity to invent truly new capabilities. All it can do is reduce the cost of existing capabilities.

Stated that way it is refutable, which is the compliment I would pay any claim, and there is a published result aimed straight at it.

In 2023 a DeepMind system called FunSearch paired a pre-trained model with "an automated 'evaluator', which guards against hallucinations and incorrect ideas", and ran that loop until it returned new constructions for the cap set problem and better heuristics for online bin packing [9]. The cap set problem is a combinatorial question where any proposed answer can be examined exhaustively by a program in seconds, and FunSearch's constructions were the largest increase in that bound in twenty years. Its authors describe the work as "the first time a new discovery has been made for challenging open problems in science or mathematics using LLMs" [9]. That is a real result and I will not explain it away. What is worth disputing is the readings of it, and there are three in circulation.

The first reading is the headline one: a machine invented something. What the case establishes is narrower. The cap set space is not large in the sense of being expensive to search; it is large in the sense that exhaustive enumeration does not finish, and budget and reachability are different axes. FunSearch ran on a well-defined problem in a thoroughly explored domain, on ground decades of prior work had made solid, and what it contributed was convergence: a generator proposing candidates and a ranker discarding the wrong ones far faster than brute force had managed. Then read what the automated evaluator implies about the target. If a program can decide that a candidate answer is wrong, the target was fully specified before the run began, and defining what is wrong had already defined what would count as right.

The second reading takes that observation one step too far and says the exception requires the automatic evaluator. It does not, and the case against it is in print. In November 2025 researchers from OpenAI and mathematicians from Cambridge, Oxford, Harvard, Columbia and Berkeley released case studies of a model in live research, and the abstract does not hedge: the paper "includes four new results in mathematics (carefully verified by the human authors)", helping human mathematicians "settle previously unsolved problems" [13]. The checking there was done by people reading proofs, so the version of my argument that needed a machine evaluator is wrong, and I have dropped it.

Read the other phrase again, though, because it is the half that survives: previously unsolved problems. Somebody had posed each of them, and what would count as an answer was fixed before the model arrived. So this is the version worth defending, and worth disagreeing with: the exception needs a target that was specified first, which is to say a question already asked and a standard capable of saying wrong about a candidate answer. Who applies that standard is negotiable. That it existed beforehand is not. One documented case of a model's output accepted as knowledge where nobody had posed the question would end that claim, and the searches behind this piece did not find one.

The nearest miss deserves naming. In May 2026 Nature published Robin, a multi-agent system that proposed enhancing retinal pigment epithelium phagocytosis as a treatment strategy for dry age-related macular degeneration and identified ripasudil, a drug its authors say "has never previously been proposed" for that indication. It then proposed and analysed its own follow-up RNA-sequencing experiment, which surfaced ABCA1 as a possible new target, and the paper states that "All hypotheses, experimental directions, data analyses and data figures in the main text of this report were produced by Robin" [14]. That is the closest thing in print, and it does not cross the line. People handed Robin the disease, so the question was posed before the model arrived; and what decided that ripasudil was worth believing was a laboratory assay run by people, which is why the paper calls its own approach semi-autonomous and its framework lab-in-the-loop. It is the cap set again, one field over: a generator, an evaluator, and the evaluator doing half the work. And notice what a human evaluator costs. In mathematics it is research mathematicians reading proofs line by line, and there are not enough of them to read a master file.

The third reading is the one that does damage in a procurement meeting: the assumption that a result of this kind transfers. It does not transfer for free. A combinatorial construction is checkable in full, by a program, against a definition nobody disputes. A customer record is checkable only against a standard somebody sat down and wrote, and kept. In master data that standard is the governed artifact: the target schema, the value sets, the survivorship rules, the labelled sample you score against. On the project where I am setting AI to fill the gaps in master data, the one data prerequisite that matters is exactly this: the required structure in place first, because that structure is the standard we are asking the model to bring the data up to. That is what can say wrong without being asked twice, and nobody sells it to you. If it was never written, what has been bought is the generator on its own, which was always the cheap part.

What the reduction actually buys

Which is where the substitution argument stops sounding deflationary. In the same answer that began by burning a budget, I named three abilities that do genuine work, and each comes with its condition attached.

Structure out of semi-structure. Pulling a defined shape from a JSON export, a supplier's product sheet, a free-text description. This is now a constrained-decoding feature rather than a prompt-and-hope one: a vendor can compile your JSON schema into a grammar and document the response as conforming to it in most cases, at the price of a compilation step, a ceiling on schema complexity and an injected system prompt whose tokens are billed to you [4]. The exceptions it names include a response cut off at the token limit, which is the same truncation a per-request output ceiling produces [7]. And conformance is not truth. A wrong value in a well-typed field satisfies the grammar and raises nothing downstream, and that is the failure that never appears in a demonstration.

Tests against code that is not finished. The best-evidenced version in public is Meta's TestGen-LLM, which filtered every generated test class for measurable improvement over the original suite before an engineer saw it. On Instagram's Reels and Stories the paper reports that "75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage", each measured against everything generated rather than against the survivors of the step before; and across two test-a-thons that "it improved 11.5% of all classes to which it was applied, with 73% of its recommendations being accepted for production deployment" [6]. The headline is not the 73%. It is that one generated test in four was worth keeping, one in three of those that even built, and that the filter rather than the generator made that difference.

Filling a gap by reasonable inference. This one is closest to the master data bone. A 2026 benchmark ran five widely used models against six established imputation methods across 29 datasets and found the models ahead of the classical baselines on real-world data and behind on synthetic data, where MICE, the workhorse that fills each gap from the other columns, won [5]. The split is the finding rather than a footnote to it: the advantage comes from semantic context absorbed in pre-training, not from statistical reconstruction. Point the model at a domain the internet has seen a great deal of and it performs; point it at your proprietary coding scheme and you are back among the statisticians.

Each of the three is something a competent team could already do, now cheap enough to do at volume, and each is answerable to a standard that existed before the model was pointed at it.

None of which stops the substitution feeling like new capability from where the buyer sits, and I do not say the buyer is wrong to feel it. The rest of my answer went here:

It can fill the role of a 'domain expert' when properly trained, but it can't do it as well as a human domain expert—whose training occurred before they were hired and includes vast amount of non-domain information as a byproduct of their life. However, if the budget for that position is only $5,000 a year and the human domain expert costs $250,000 annually, all expenses included, it can seem that the AI provides new capabilities to the company because now they can have an imitation expert with some limitations for a tiny fraction of the cost.

Those are round numbers on purpose, and neither is a rate, a contract or a measured salary; what does the work is the ratio, roughly fifty to one. Be careful which half you lean on, because a fully loaded salary is a figure the organisation has been paying for years, while the five thousand is a forecast nobody has yet learned to bound. At fifty to one, though, the distinction between cheaper and new stops being visible from the buying committee. An imitation expert with known limitations at that price is a capability you did not have, not because anything was invented but because the price fell below the line where you were permitted to want it. The word I would still defend in that answer is seem. The buyer is not deceived about the result, only about its cause, and the cause is what decides whether the result will hold when the price moves.

Vagueness is the meter

Which moves the question onto the price, and the price has a mechanism under it that explains most of the disappointments. The same answer named it:

The more complicated and vague the problem at which its pointed, the more expensive it is to provide a solution—and the solution isn't even guaranteed to be right.

Plenty of your estate is metered by consumption already, down to the elastic cluster nobody turned off, so imprecision costing money is not the novelty here. Three narrower properties are. The coupling is tighter, because the vagueness of the instruction is itself the price driver: a model handed an underspecified problem spends more tokens working out what was meant. It is invisible in advance, since there is no plan to read before the run, only a bill afterwards. And it cannot be attributed, because you cannot point at the clause that spent the money the way you can point at a missing index.

Vendors have stopped hiding this and started selling controls for it. One publishes an effort parameter with five levels, whose general table describes the lowest as "Significant token savings with some capability reduction", and whose guidance for one model, which the page says overrides the general table wherever the two differ, warns that on most workloads the maximum "adds significant cost for relatively small quality gains" [3]. Read the scoping as carefully as the warning. That sentence is a per-model note, not a property of the parameter: the same page's guidance for a newer model recommends stepping up to the maximum "when a task justifies unconstrained token spending", so the caution and its reversal sit under one heading. Those control surfaces are one vendor's, read on a given day and stated per model; read your own, and date them.

The imputation benchmark carries the same shape from the other direction, since the models that won on quality "incur significantly higher computational time and monetary costs" than the classical methods they beat [5]. Nobody found a free lunch. They found a better lunch and an itemised bill, and the bill is the part that generalises: the specificity of the instruction is a cost driver in its own right, separate from volume. Clean up the supplier names is expensive and unverifiable in the same breath. An instruction naming the value set, demanding one of seventeen codes or an explicit unresolved marker, with a confidence figure alongside, is cheap, checkable and answerable at a low effort setting. Same records, materially different invoice, and the difference is the standard somebody wrote before the call was made.

It is also why my own habit runs the other way from the default. I start a model one generation behind the current main line, and two behind the bleeding edge, at the smallest token budget a request allows; I put the effort into the prompt, and step up only until the returns start to diminish. Most of what master data asks of a model is not difficult. It is repetitive and time-consuming, and what that needs is basic domain competence, which can be written into the instruction rather than bought as a larger model.

The budget stops. The work does not.

Then the failure that catches people. A tool this flexible invites you to reach for it for too much and too often, and to exhaust a token allocation in a fraction of the time the plan assumed. The instinctive answer, the one every finance function reaches for, is a hard limit, and my objection to it was this:

We don't really know all of the 'capabilities' AI is bringing to the table and we especially don't know how to ensure we don't outrun our budget with AI. It's all well and good to have token budgets and hard limits on spending, but just because the budget is exhausted doesn't mean the data is.

Sit with the asymmetry. A spending cap bounds what you pay for and holds no opinion about the records still unenriched in the queue on the first of the month; what stopped was the payment. The caps are also softer than the word suggests. One vendor's per-task budget is documented as "a soft hint, not a hard cap", which the model "may occasionally exceed" if it is in the middle of an action, with the enforced ceiling living elsewhere, in a per-request output limit that truncates the answer where it stands. The documented behaviour of an undersized budget is that the model "may decline to attempt the task at all, scope it down aggressively, or stop early with a partial result" [7]. Set it loose and it does not cap. Set it tight and you have not bought restraint; you have bought a queue of half-processed records with no error to alert on. That is the worst condition a master data pipeline can be in, because it looks exactly like one that ran.

The part that is about control rather than price

All of which stays manageable while the process is optional, and changes character once it is not. This is the argument the differentiator framing is structurally unable to make. My advice on positioning AI-enhanced master data inside a business is to undersell it rather than oversell it, and it ends on a warning:

Tread very lightly when incorporating AI into vital business processes because now it becomes load bearing for the business

and, I added, the cost of it is then no longer the business's to control. Load-bearing is the exact word, and it is structural rather than financial, which is why it fits neither label. The reasonable objection is that none of this is unusual: every load-bearing system you own already runs on a price somebody else sets, between the platform, the database, the cloud and the maintenance uplift nobody asked for. Fair, and the answer sits in the published terms.

An enterprise platform's end of life arrives on a horizon measured in years, usually with a supported upgrade path, and asks for a migration you can schedule: recompile, re-certify, regression-test the logic you have. A model retirement arrives with "at least 60 days' notice" at the floor, the vendor publishing tentative dates further out, and its three most recent retirements having run sixty, sixty-one and sixty-two days from announcement to shutoff; after the date, "Requests to models past the retirement date will fail" [8]. It asks for a re-tuning instead: thresholds, prompts and confidence bands calibrated against one model's behaviour have to be re-derived against another's, and the only way to learn whether they hold is to run them and look. So the distinction is not a price you do not set, since you never set any of them. It is a price you do not set, on a calendar you do not keep, governing behaviour you calibrated against and cannot pin down. The first is procurement; all three at once is what load-bearing means here.

The third of those, behaviour I calibrated against and cannot pin down, is no longer a forecast for me. It has happened under my own production pipeline, which is not master data but the model-backed tooling I build and publish with. The model under it was replaced with a newer one, my default effort setting dropped from high to medium, and on my own reading my usage allowance ran down faster than its recent trend in a week when I was using the tool less than usual. The vendor's note on the new model documents two effects that pull in opposite directions. A request that omits the effort setting now runs at medium, where "on Claude Opus 5 it ran at high", which should spend fewer tokens; and "At the same effort setting the model tends to think more per turn than Claude Opus 5", which spends more. The list price is lower as well: $4 and $20 per million input and output tokens, "below Claude Opus 5's $5 and $25" [15]. The page does not compare the new model at medium with the old one at high, and how I was working that week is part of what counted against that allowance, a confound I cannot separate out. So the rate card fell and, by my observation rather than any measurement, the consumption rose. What the episode does show is that the tokens a result takes are the vendor's to change, and that they changed with the model. I offer it as an instance of the concern, not as a complaint about one vendor.

There is one genuine escape, and it should be priced rather than waved at. Open-weight models exist and can be served on infrastructure you own. One current family ships instruction-tuned weights at several sizes with a 128K context window on its larger models, positioned for deployment "in environments with limited resources such as laptops, desktops or your own cloud infrastructure", with documented serving through vLLM, SGLang, Docker and quantized runtimes [11]. Nobody can retire a model you hold and nobody can reprice it, so the sweeping form of the control argument is false for anyone willing to self-host. What you pay instead is knowable in three parts, though the invoice is not. The bill changes species: you stop paying per call and start paying for capacity sized to your peak, so the money leaves whether the queue is full or empty. You acquire a standing operations job that used to be somebody else's, and it cuts both ways: nobody retires your model and nobody improves it, so reaching the next one becomes a project you fund rather than inherit. And the quality question becomes yours, which lands back on the imputation result: if the advantage came from what was absorbed in pre-training, a smaller model is not merely cheaper, it has had less of your domain pass through it [5], and the harness that says whether it still has enough is yours to build and run.

There is also a middle path, pricing the identical trade in the open. One major cloud sells model invocation capacity "at a fixed cost", billed hourly per model unit, with a commitment of none, one month or six, noting that "the longer the commitment duration, the more discounted the hourly price becomes", and stating plainly that under a term "You can't delete the Provisioned Throughput until the one month commitment term is over" and that "Billing continues until you delete the Provisioned Throughput" [12]. That is real price certainty, sold without pretence, and it is worth noticing what buys it: a variable cost converted into an obligation you cannot leave. Control is purchasable and never free, and the currency is always some other commitment.

Which is where the accountants in the room stop nodding, and they are right to. An ordinary variable cost has a unit underneath it, per record or per call or per shipment, and the unit is what lets you multiply by volume, charge the cost to what caused it and defend the line in a business case. This one has no stable unit. The cost of a single result moves with the model you were routed to, with the length of the prompt and whatever context it dragged in, and with the supplier's next price change, so two identical records processed a month apart are two different numbers on the same report. When I read this argument back, I put the accountants' problem more shortly: the difficulty is that

you can't tie the variable cost to a produced result as the per result cost is, itself, variable.

I called it a real conundrum, and it is also what a commitment term is selling. It is not selling a lower price. It is selling a denominator.

What I would watch for

Here the warrant changes: what follows rests on what my own work has taught me to check rather than on the sources above, and it is offered as pattern rather than law. Four things, in the order they tend to bite.

A cost model with no vagueness term in it. Most AI cost models for master data are built from record volume and a unit price. Volume is not the driver; specification is. A model with no line that moves when the instruction moves will be wrong in a direction nobody can predict, and unlike a volume error this one worsens as you succeed, because the successful pilot is what earns you the vaguer second use case. The term is measurable this week, because your vendor sells the instrument: run one sample of records twice, the loose instruction at a high effort setting and the fully specified one at a low setting [3], and set the two bills beside the quality each bought. The searches behind this piece turned up no published cost measurement of AI-augmented master data at enterprise scale, and two runs and an invoice would beat one anyway.

The cap that was never tested by exhausting it. The question I ask of any roadmap that puts AI into master data work is whether a token budget comes attached to it, and whether there is a phase before full rollout whose job is to prove that budget holds. The next question is what happens on the day the allocation runs out, and we'll get an alert is not an answer. Who works the queue? Does the pipeline fail loudly, or return a partial result that looks like a whole one [7]? A limit nobody has deliberately hit is a limit nobody has tested, and the first test will otherwise be run in production at month-end by whoever is on call.

The generator with no evaluator. This is the one I would defend hardest, and it is the lesson that transfers from the two cases that broke the stronger form of my own claim: in both, the evaluator did as much work as the generator, and in one it was a person [9] [13]. My own rule, from building with these models, is that a gate nobody enforces is only a suggestion; a model left to reach an answer will take the shortest road to one, and an intermediate check it must pass is what keeps it on the road. A proposal that cannot say what would reject a wrong answer, and who or what applies that test at your volume, is not an AI project. It is an AI demonstration.

A claim of practice experience that is really a claim of product experience. The question for a supplier is how long the capability has been running in production at a customer, at what volume, and what broke. I hold myself to the same question, and my own answer is that I have not yet run governed AI enrichment on a master data foundation. Building the capability and operating it are two separate jobs, and the order matters: nothing a proof of concept shows means much until the infrastructure under it exists. Anyone who tells you they have years of this should be able to tell you what went wrong in them.

And the claim to be most sceptical of is the modest-sounding one: that the spending is bounded because a limit has been set. It is bounded in one direction only. My advice is to make the understated case, not out of modesty but because nobody yet knows the full set of capabilities, nor how to keep any of them inside a budget, and overselling a thing whose costs cannot be bounded is how a differentiator becomes the cost centre it replaced.

Where to go deeper

Your own model vendor's deprecation and pricing pages, the developer documentation rather than the marketing site, and specifically the lifecycle page [8]. That is the actual contract, and the retirement dates read as a project plan. Read the release note for each new model as well [15], for what it changes in the defaults you did not set.

The same vendor's cost-control documentation: effort or reasoning parameters [3], task budgets and their enforcement semantics [7], structured output [4], and what capacity costs under a commitment term [12]. Those are the dials that decide your bill.

Alshahwan, Chheda, Finegenova, Gokkaya, Harman, Harper, Marginean, Sengupta and Wang, Automated Unit Test Improvement using Large Language Models at Meta (FSE 2024) [6], for the filter architecture rather than the subject matter: the clearest published account of assuring model output by discarding whatever cannot be shown to improve on what you had.

Romera-Paredes, Barekatain, Novikov et al., Mathematical discoveries from program search with large language models (Nature, 2023) [9], alongside Bubeck, Coester, Eldan, Gowers et al., Early science acceleration experiments with GPT-5 (2025) [13], the two strongest published cases against the argument made here. Notice how much of the first is the evaluator, and who the evaluator is in the second.

The 2026 imputation benchmark [5], for quality against cost across 29 datasets and for the synthetic-data result, which says where the capability comes from.

Kannangara and seven co-authors, A Robust and Efficient Pipeline for Enterprise-Level Large-Scale Entity Resolution (2025) [10], the thing this field has too few of: people reporting what they built, at what scale, against named alternatives.

The label was never the argument

So the honest translation of differentiator, when a deck says it, is that a vital process is moving onto a supplier's release schedule in exchange for a large, real and probably temporary reduction in what the work costs to do. Some of those trades are worth making. Enrichment that is genuinely optional this quarter is a reasonable place to begin, the failure there being a slower queue rather than a stopped business; identity resolution in the middle of customer onboarding deserves the harder version of the question. A business case that uses the word owes a column for the second half of that trade, and the label gives it no place to put one.

Neither label was ever going to supply it, because both sort on the ledger. The question that does is the one to ask of every process the proposal names, before the word goes into the deck: of the work you are about to make impossible to stop, how much of it will run at a price, on a calendar and with a behaviour that somebody else sets?

An earlier version of this piece — written before this publication rebuilt how its voices are generated — is published unedited at Load-Bearing: The Question to Ask Before AI-Enhanced MDM Becomes Your Differentiator (original), so the two can be read side by side. The account of why is at The Voice Problem.

References

[1] Informatica, How Master Data Management (MDM) Should Shape Your AI Strategy (reference article) — a five-step AI-strategy sequence (perform a data readiness assessment, implement master data management, build the infrastructure for scalability, automate data workflows, monitor for continuous improvement), with the quoted authority identified as the vendor's Sr. Director, Product Marketing, MDM & 360 Applications, and closing on the vendor's own platform and AI component. Read August 21, 2026; re-read September 26, 2026. Cited as a representative sample of the material that circulates under the heading of best practice, not as evidence of value. https://www.informatica.com/resources/articles/ai-strategy-mdm.html

[2] Gartner press release, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (June 25, 2025) — "over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls"; "agent washing" described as rebranding existing products without substantial agentic capability, with an estimate that only about 130 of thousands of agentic AI vendors are real; and a January 2025 poll of 3,412 webinar attendees reporting investment posture rather than outcomes. Re-read September 26, 2026. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

[3] Anthropic, Effort (Claude Platform documentation) — five effort levels (low, medium, high, xhigh, max). In the general table, "low" is "Most efficient. Significant token savings with some capability reduction." The page states that "The per-model recommendations that follow override this table where they differ"; the warning "On most workloads max adds significant cost for relatively small quality gains, and on some structured-output or less intelligence-sensitive tasks it can lead to overthinking" appears in the per-model guidance for Claude Opus 4.7, while the guidance for Claude Opus 5 recommends stepping up "to max when a task justifies unconstrained token spending". Read August 21 and September 4, 2026; re-read September 26, 2026. Cited for what the control is and what the vendor documents it costing, not as a recommendation of a product. https://platform.claude.com/docs/en/build-with-claude/effort

[4] Anthropic, Structured outputs (Claude Platform documentation) — constrained decoding described as guaranteeing schema-compliant responses, qualified on the same page: "While structured outputs guarantee schema compliance in most cases, there are scenarios where the output may not match your schema", namely a refusal (stop_reason: "refusal"), a response cut off at the token limit (stop_reason: "max_tokens", where "The output may be incomplete and not match your schema"), and enum values returned in different casing. Also documented: costs and limits: added latency the first time a schema's grammar compiles, compiled grammars "cached for 24 hours from last use", an automatically injected system prompt so that "Your input token count is slightly higher", and complexity limits of 20 strict tools, 24 optional parameters and 16 union-typed parameters per request. Read August 21, 2026; re-read September 26, 2026. https://platform.claude.com/docs/en/build-with-claude/structured-outputs

[5] Large Language Models for Missing Data Imputation: Understanding Behavior, Hallucination Effects, and Control Mechanisms, arXiv:2603.22332 — a benchmark of five LLMs against six imputation baselines across 29 datasets (nine synthetic). Reports superior LLM performance on real-world datasets and underperformance against MICE on synthetic data, concluding that "LLM effectiveness is driven by semantic context rather than purely statistical reconstruction", and that "while LLMs excel in imputation quality, they incur significantly higher computational time and monetary costs." Abstract read at source August 21, 2026 and re-read September 26, 2026; the full paper was not read. https://arxiv.org/abs/2603.22332

[6] Nadia Alshahwan, Jubin Chheda, Anastasia Finegenova, Beliz Gokkaya, Mark Harman, Inna Harper, Alexandru Marginean, Shubho Sengupta and Eddy Wang, Automated Unit Test Improvement using Large Language Models at Meta, arXiv:2402.09171 (32nd ACM Symposium on the Foundations of Software Engineering, 2024) — TestGen-LLM filters every generated test class for measurable improvement over the original suite before an engineer sees it; the abstract reports that on Instagram Reels and Stories "75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage", and that across test-a-thons "it improved 11.5% of all classes to which it was applied, with 73% of its recommendations being accepted for production deployment by Meta software engineers." Abstract read at source September 4, 2026. https://arxiv.org/abs/2402.09171

[7] Anthropic, Task budgets (Claude Platform documentation, beta) — a per-task token budget documented as "a soft hint, not a hard cap", which Claude "may occasionally exceed" if it is in the middle of an action; "The enforced limit on total output tokens is still max_tokens, which truncates the response"; and, where a budget is clearly insufficient, the model "may decline to attempt the task at all, scope it down aggressively, or stop early with a partial result rather than start work it cannot finish." Read August 21, 2026; re-read September 26, 2026. https://platform.claude.com/docs/en/build-with-claude/task-budgets

[8] Anthropic, Model deprecations (Claude Platform documentation) — "providing at least 60 days' notice before model retirement for publicly released models"; "Requests to models past the retirement date will fail"; a model-status table whose forward entries are headed "Tentative retirement date" and read "Not sooner than" dates running into 2027; and a deprecation history whose three most recent announcements ran 60, 61 and 62 days to shutoff (Opus 4.1, June 5 to August 5, 2026; Sonnet 4 and Opus 4, April 14 to June 15, 2026; Haiku 3, February 19 to April 20, 2026). Read August 21 and 23, 2026; re-read September 26, 2026. Cited as a published example of vendor-side lifecycle terms, not as a criticism of this vendor's policy. https://platform.claude.com/docs/en/about-claude/model-deprecations

[9] Alhussein Fawzi and Bernardino Romera-Paredes, FunSearch: Making new discoveries in mathematical sciences using Large Language Models, Google DeepMind (December 14, 2023), accompanying Mathematical discoveries from program search with large language models, Nature (DOI 10.1038/s41586-023-06924-6) — a pre-trained LLM paired with "an automated 'evaluator', which guards against hallucinations and incorrect ideas"; "the first time a new discovery has been made for challenging open problems in science or mathematics using LLMs"; "the largest increase in the size of cap sets in the past 20 years"; and improved online bin-packing heuristics. The DeepMind post was read at source August 21 and September 26, 2026; the Nature article itself was not opened and is cited bibliographically. https://deepmind.google/blog/funsearch-making-new-discoveries-in-mathematical-sciences-using-large-language-models/

[10] Sandeepa Kannangara, Arman Abrahamyan, Daniel Elias, Thomas Kilby, Nadav Dar, Luiz Pizzato, Anna Leontjeva and Dan Jermyn, A Robust and Efficient Pipeline for Enterprise-Level Large-Scale Entity Resolution, arXiv:2508.03767 (August 5, 2025) — the MERAI pipeline, compared against the Dedupe and Splink libraries: "While Dedupe failed to scale beyond 2 million records due to memory constraints, MERAI successfully processed datasets of up to 15.7 million records", with consistently higher F1 scores on both tasks. Section V records application to bank projects "processing up to 33 million records" and states that "The pipeline consistently handled extensive datasets without any failures in all the projects where it was employed within the bank." Full text read at source September 4, 2026; abstract re-read September 26, 2026. The paper reports no operating duration; the limitations it discusses are those of Dedupe, Splink and Magellan; and its stated future work is a feature-engineering improvement. https://arxiv.org/abs/2508.03767

[11] Google DeepMind, Gemma 3 model card (google/gemma-3-27b-it on Hugging Face) — open weights for pre-trained and instruction-tuned variants across several sizes, "a large, 128K context window" on the 4B, 12B and 27B models, and the stated design intent that their "relatively small size makes it possible to deploy them in environments with limited resources such as laptops, desktops or your own cloud infrastructure"; the page documents serving through vLLM, SGLang, Docker and quantized runtimes. Read August 21, 2026; re-read September 26, 2026. Cited for what open-weight distribution makes possible, not as a recommendation of any model. https://huggingface.co/google/gemma-3-27b-it

[12] Amazon Web Services, Increase model invocation capacity with Provisioned Throughput in Amazon Bedrock (Amazon Bedrock User Guide) — capacity "at a fixed cost", billed hourly per Model Unit, with commitment options of none, one month or six months, and the note that "The longer the commitment duration, the more discounted the hourly price becomes"; under a term, "You can't delete the Provisioned Throughput until the one month commitment term is over", and "Billing continues until you delete the Provisioned Throughput." Read August 21, 2026; re-read September 26, 2026. Cited for the documented commercial terms of buying price certainty, not as a recommendation of a platform. https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html

[13] Sébastien Bubeck, Christian Coester, Ronen Eldan, Timothy Gowers, Yin Tat Lee, Alexandru Lupsasca, Mehtaab Sawhney, Robert Scherrer, Mark Sellke, Brian K. Spears, Derya Unutmaz, Kevin Weil, Steven Yin and Nikita Zhivotovskiy, Early science acceleration experiments with GPT-5, arXiv:2511.16072 (November 20, 2025) — case studies of GPT-5 contributing to live research, with author affiliations spanning OpenAI, Oxford, Cambridge, Columbia, Harvard, UC Berkeley and others. The abstract states that the paper "includes four new results in mathematics (carefully verified by the human authors), underscoring how GPT-5 can help human mathematicians settle previously unsolved problems." Read at source August 23, 2026: the abstract, the introduction, the table of contents, Chapter I.1 and Chapter II.2; the retrievable text stopped part way through Chapter III, so the Chapter IV proofs were not reached, and nothing above depends on their internals. https://arxiv.org/abs/2511.16072

[14] Ali E. Ghareeb, Benjamin Chang, Ludovico Mitchener, Angela Yiu, Caralyn J. Szostkiewicz, Dmytro Shved, Gavin J. Gyimesi, Jon M. Laurent, Samantha M. Wright, Muhammed T. Razzak, Andrew D. White, Silvia C. Finnemann, Michaela M. Hinks and Samuel G. Rodriques, A multi-agent system for automating scientific discovery, Nature 655, 497–505 (published online May 19, 2026; DOI 10.1038/s41586-026-10652-y) — the Robin system. The abstract states that ripasudil "has never previously been proposed for the treatment of dry age-related macular degeneration" and that "All hypotheses, experimental directions, data analyses and data figures in the main text of this report were produced by Robin"; the paper describes "a semi-autonomous approach to scientific discovery" and "an iterative lab-in-the-loop framework", in which the humans supplied the disease of interest and ran the laboratory experiments. Abstract, introduction and results read at source September 4, 2026; abstract re-read September 26, 2026; the supplementary information was not opened. https://doi.org/10.1038/s41586-026-10652-y

[15] Anthropic, What's new in Claude Opus 5.5 (Claude Platform documentation) — "A request that omits effort runs at medium; on Claude Opus 5 it ran at high"; "At the same effort setting the model tends to think more per turn than Claude Opus 5, most of all at xhigh and max"; and pricing of "$4 USD per million input tokens and $20 USD per million output tokens, below Claude Opus 5's $5 and $25." The page compares with Claude Opus 5 and does not state a retirement of any earlier model; the account of the change in the body is the practitioner's own. Read at source September 26, 2026. https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5