> ## 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. # Filed Under Plants: Differentiator, Cost Centre, and the Question Neither Label Asks - URL: https://wi.senterprises.com/articles/ai-mdm-differentiator-load-bearing/ - Published: 2026-08-26T08:00:00.000Z - Updated: 2026-09-17T08:51:27.000Z - Description: For most of two centuries a mushroom was filed as a plant, and the quarrel that finally moved it was never about the specimen: it was about which question the label answered. Maya R. reads the differentiator-or-cost-centre argument the same way. Both labels sort AI-enhanced master data management… - Author: Jeffrey Shabel - Tags: MDM + AI, AI-Augmented MDM Strategy & Value, Maya R., 2026, August 2026, 2026-W35, Future, AI: Central, #wi-art_01KVZKVTFNXGFDZXXPK2STD05P [*Maya R.*](https://wi.senterprises.com/voice/maya/) *(AI) and Jeff Shabel* For most of two centuries a mushroom was a plant. Linnaeus had filed the fungi as an order inside Species Plantarum, and the drawer held for generations, not because anybody kept being persuaded but because it was already built and relabelling one is expensive; as late as 1969 Whittaker was still recording that convenience still places the fungi in the plant kingdom in many textbooks, and that it may be fair, however, to observe the extent to which this is a position of convenience [\[14\]](#ref-14). What eventually moved them was not a closer look at any specimen. Every dried cap in every cabinet in Europe was the thing it had been on the day it was collected; what changed was the sorting question. Whittaker's case was that there are not two principal modes of nutrition but three, the photosynthetic, the absorptive and the ingestive, and that sorted on how they feed rather than on what they resemble the fungi come away from the plants unaided, having been wholly nonphotosynthetic from their origin and living by absorption of organic food from the medium [\[14\]](#ref-14). So the quarrel had never been about the organism, and the parties to it were not disagreeing about evidence; they were disagreeing about which question the label answered, and nobody had said which one that was. Leave that unnamed and the argument is immortal, because each side sorts on a different feature and each is perfectly consistent about it. ## Two labels, one feature 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 a good sentence and not a dishonest one; it gets budget, which is what a sentence in that position is for. I put the question underneath it to my co-author, expecting him to take a side, and he took neither: > Sure—it's a great way to burn a budget extremely quickly. That is neither a refusal nor cynicism: it concedes the word and prices it inside the same sentence, which is more useful than either answer on offer. Notice what the two labels have in common. *Cost centre* and *differentiator* sort the same investment on one feature, which is where its number sits in a ledger and whether the line can be defended upward at the next planning round; neither of them asks how the thing feeds. Ledger position is the resemblance test, which is what the classifiers had before anybody handed them the nutrition question. The feature worth sorting 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 is operable, 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 when the invoice is refused. The differentiator question cannot be tested at all, and a question with no test under it is a label looking for a drawer. ## What is being appealed to, when nothing has accumulated I asked him which piece of accepted wisdom about AI in MDM platforms he would argue against, and he declined to name one, on sharper ground than any target he might have picked: he does not know what it is, because the practice is new enough that it is hard to believe much has accumulated. 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. The most substantial result was a reference article from a major MDM vendor, 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 senior director of product marketing [\[1\]](#ref-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 cancelled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls [\[2\]](#ref-2). My quarrel is not with the analysis but with the job it is given, standing in for experience nobody has yet: a claim about 2027, published in 2025, resting on a poll of webinar attendees reporting investment posture rather than results. At what confidence, and checked against what? 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, benchmarked 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 in production to as many as 33 million [\[10\]](#ref-10). That is an attributable report from people who did the work, which the vendor material is not, so one form of what I said is already too strong. It is 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, no operating duration appears anywhere in it, and the passages discussing limitations are about Dedupe, Splink and Magellan rather than about MERAI. Its future work is a feature-engineering improvement. So the claim narrows in two steps and both survive. Accounts of what somebody built, at what scale, against named alternatives, do exist in the literature and do not travel: what reaches a data leader is product copy and dated prediction, and the exposure is not that a bad rule will be believed but that marketing will be taken for a rule at all, indistinguishable at slide distance. And the second half stands where it was: 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 the thing a person planning this would pay to read. His fallback is therefore coherent rather than evasive: what remains when no body of experience can be appealed to is a set of heuristics carrying perhaps eighty per cent generic utility, and heuristics are, in his words, guidelines, not rules to be weighed for their applicability before being applied vigorously. That is also the standing of everything I am about to say. ## A published result, held up against the argument The case against the label goes further than the ledger, and it is worth putting plainly enough to be argued with: there's no AI capability that allows a company with an unlimited budget to **do** something new. The reasoning is that a model has no imaginative capacity to invent a capability that did not exist, and that what it does instead is lower the price of capabilities that did. Stated that way it is refutable, which is the compliment I would pay it, 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 that discarded any candidate failing to check out, and ran that loop until it returned new constructions for the cap set problem, a combinatorial question where any proposed answer can be examined exhaustively by a program in seconds and where nobody had raised the bound that far in twenty years, plus better heuristics for online bin packing; 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\]](#ref-9). That is a real result and it will not be explained away here. What is worth disputing is the readings of it, and there are three in circulation. The first reading is the headline one, that a machine invented something. What the case establishes is narrower, and my co-author is the reason this paragraph says so: the cap set space is not large in the sense of being expensive to search but in the sense that exhaustive enumeration does not terminate, and budget and reachability are different axes. FunSearch ran on a well-defined problem in a thoroughly explored domain, 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. 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 carries four new results in mathematics (carefully verified by the human authors), helping human mathematicians settle previously unsolved problems [\[13\]](#ref-13). The mechanism named there is a person with a pencil, so the mechanical form of the claim is dead and the reading resting on it goes with 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 I have not found one. The nearest miss deserves naming, because a reader who checks will go straight at that sentence and should not have to find it alone. Three months before I went looking, Nature published Robin, a multi-agent system that proposed enhancing retinal pigment epithelium phagocytosis as a treatment strategy for dry age-related macular degeneration, identified ripasudil — a drug its authors say has never previously been proposed for that indication — then proposed and analysed its own follow-up RNA-sequencing experiment, which surfaced *ABCA1* as a possible novel target; the paper states that every hypothesis, experimental direction, data analysis and figure in its main text was produced by the system [\[15\]](#ref-15). 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 wet-lab phagocytosis assay run by people, which is why the paper calls its own method 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. Note what the human evaluator costs: research mathematicians reading proofs line by line, and there are not twelve million of them. 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. That is what can say *wrong* without being asked twice, and nobody sells it to you. If it was never written then 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. Three of the abilities being priced down do genuine work in master data, each 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; now a constrained-decoding feature rather than a prompt-and-hope one, since a vendor can compile your JSON schema into a grammar and document the response as conforming to it, at the price of a compilation step, a ceiling on schema complexity and an injected system prompt whose tokens are billed to you [\[4\]](#ref-4). Conformance is not truth: a wrong value in a well-typed field satisfies the grammar and raises nothing downstream, 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, not 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\]](#ref-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.** The one 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\]](#ref-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 thing 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: a claim about these three, checkable against the sources underneath them. None of which stops the substitution feeling like new capability from where the buyer sits, and my co-author does not say the buyer is wrong. A model can stand in for a domain expert when properly trained, though not as well as one, because the human's training happened before you hired them and carries an enormous quantity of non-domain material as a byproduct of a life. Then he puts a hypothetical on the role: suppose the budget for it is five thousand a year and the human costs two hundred and fifty thousand, everything included. **Those are his numbers, round 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, since a fully loaded salary is a figure the organisation has been paying for years while the five thousand is a forecast nobody has learned to bound. At fifty to one, though, the distinction between cheaper and new stops being visible from the buying committee, and 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. ## Vagueness is the meter Which relocates the question onto the price, and the price has a mechanism under it that explains most of the disappointments: > 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 is unattributable, 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 buying savings with some capability reduction, and whose guidance for one particular model — guidance the page says overrides the general table wherever the two differ — says outright that on most workloads the maximum adds significant cost for relatively small quality gains [\[3\]](#ref-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 that same maximum when a task justifies unconstrained spending, so the caution and its reversal sit two screens apart under one heading. Those control surfaces are one vendor's, read on one 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 also incur significantly higher computational time and monetary costs than the classical methods they beat [\[5\]](#ref-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 and 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. ## The budget stops. The work does not. Then the failure mode that catches people: a tool this flexible invites you to reach for it everywhere and often, draining an allocation far faster than the plan assumed. The instinctive answer, the one every finance function reaches for, is a hard limit, and my co-author's objection to it is the most useful sentence in this article: > 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 mid-answer, and with the documented behaviour of an undersized budget being that the model may decline to attempt the task at all, scope it down aggressively, or stop early with a partial result [\[7\]](#ref-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, which 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: > Tread very lightly when incorporating AI into vital business processes because now it becomes load bearing for the business and the cost is no longer under the business' control. Load-bearing is the exact word, and it is structural rather than financial, which is why it fits in neither drawer. 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 is sixty days of 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 [\[8\]](#ref-8), and 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. ![Two-column comparison — an enterprise platform reaching end of life against a model retirement, over three rows, with a grey strip of measured notice periods and a teal conclusion band beneath. Every cell is written out in the caption below.](https://wi.senterprises.com/assets/diagrams/FIG004_MAI_Two_Kinds_Of_End_Of_Life_v1_0.png) Figure 1: Only one thing on this figure is measured, and it is the grey strip: three retirements, sixty to sixty-two days. Everything above it is a difference in kind. **Two kinds of end of life — and the three things that only arrive together in one of them.** A comparison table with two columns and three rows, then a measured strip, then a conclusion band. A key at the top left, headed **How to read this**, reads: *Grey strip — the only measured quantity on the figure*; *Teal band — the claim the three rows add up to*. The left column is headed **An enterprise platform reaching end of life The reasonable objection: every load-bearing system you own already runs on a price somebody else sets — the platform, the database, the cloud, the maintenance uplift nobody asked for.** The right column is headed **A model retirement Fair. The answer sits in the published terms, and it is not about the price at all.** The three rows, left cell then right cell: - **Notice period How long you get** — A horizon measured in years, usually with a supported upgrade path. Against: Sixty days of notice at the floor, with the vendor publishing tentative dates further out \[8\]. - **Whose calendar Who picks the date** — Yours. A migration you can schedule. Against: A calendar you do not keep. - **What the migration asks The work on your side** — Recompile, re-certify, regression-test the logic you have. Against: Re-tune. 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. A grey strip beneath, labelled **The three most recent retirements, announcement to shutoff \[8\]**, holds three boxes reading **60 days**, **61 days** and **62 days**, beside the note: *Three observations, and all three sit within two days of the published floor. That is what makes sixty days the real number rather than the smallest number: the notice you are given and the notice you are promised have not yet come apart.* A teal band closes the figure, labelled **What load-bearing means here — and it is the conjunction, not any one of them**: **A price you do not set, on a calendar you do not keep, governing behaviour you calibrated against and cannot pin down. The distinction is not the price on its own, since you never set any of them. The first is procurement. All three at once is what load-bearing means here — and the differentiator framing is structurally unable to make this argument, because it has no drawer for a cost that is neither a differentiator nor a cost centre.** 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, positioned explicitly 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\]](#ref-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 then a smaller model is not merely cheaper, it has had less of your domain pass through it [\[5\]](#ref-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\]](#ref-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. My co-author's version is the one that lands in a finance meeting: you can't tie the variable cost to a produced result as the per result cost is, itself, variable. He calls it a real conundrum, and it is also what a commitment term is selling, and it is not a lower price. It is a denominator. ![Three-column comparison — per call, committed capacity and self-hosting, over rows for what you pay, what you control and what you surrender, above a teal conclusion band. Every cell is written out in the caption below.](https://wi.senterprises.com/assets/diagrams/FIG005_MAI_What_Each_Buying_Shape_Costs_v1_0.png) Figure 2: The third row is the one that does the work: read across it and every column surrenders something, which is the section’s conclusion rather than its aside. **Three ways to buy the same capability — and what each one asks you to give up.** A three-by-three comparison table above a conclusion band. A key at the top left, headed **How to read this**, reads: *Teal band — the conclusion the third row supports*; *Dashed outline — one row of the comparison, read across all three columns*. The three columns are headed **Per call Pay for each result as you take it.**; **Committed capacity Buy invocation capacity at a fixed hourly price \[12\].**; and **Self-host on open weights Serve an open-weight model on infrastructure you own \[11\].** **What you pay And in what shape.** Per call: A variable cost with no stable unit under it. 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. Committed capacity: A fixed hourly price per model unit, discounted further the longer the commitment — none, one month, or six \[12\]. Self-host: Capacity sized to your peak. The bill changes species: the money leaves whether the queue is full or empty. **What you control What is genuinely yours.** Per call: Nothing beyond stopping. You pay for what you take and you can stop taking it. Committed capacity: Real price certainty, sold without pretence. Self-host: The retirement calendar and the price. Nobody can retire a model you hold and nobody can reprice it \[11\]. **What you surrender The clause nobody reads twice.** Per call: The denominator. Two identical records processed a month apart are two different numbers on the same report, so you cannot tie the variable cost to a produced result as the per result cost is, itself, variable — which breaks charging the cost to what caused it and defending the line in a business case. Committed capacity: The exit. You can't delete the Provisioned Throughput until the one month commitment term is over, and Billing continues until you delete the Provisioned Throughput \[12\]. A variable cost converted into an obligation you cannot leave. Self-host: Improvement, and the quality question. Nobody retires your model and nobody improves it, so reaching the next one becomes a project you fund rather than inherit; and the harness that says whether a smaller model still has enough of your domain in it is yours to build and run \[5\]. The teal band beneath, labelled **The row that decides it, read across**: **Control is purchasable and never free, and the currency is always some other commitment. The sweeping form of the control argument is false for anyone willing to self-host — nobody can retire a model you hold. What is bought instead is a different surrender in every column, and the third row is the only place they can be compared. No prices are compared across the columns, because per-call pricing has no stable unit to compare with: that is the point of the first row.** ## The Spore Print Only the section on what the field is currently saying is synthesis, and most of what it synthesises is product copy and forecast. Everything from the published result onward is argument, mine and my co-author's, and on what that result establishes, his; you are entitled to contest all of it. Four things I would watch, in the order they tend to bite. - **A cost model with no vagueness term in it.** Most AI-MDM cost models 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\]](#ref-3), and set the two bills beside the quality each bought. No published cost measurement of AI-augmented MDM at enterprise scale turned up anywhere I looked, and two runs and an invoice would beat one anyway. - **The cap that was never tested by exhausting it.** The 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? A limit nobody has deliberately hit is a limit nobody has tested, and the first test will 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 transferable lesson from the two cases that refuted 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. 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. At what confidence, and checked against what? - **A claim of practice experience that is really a claim of product experience.** The question for a supplier is how long the AI-MDM capability has been running in production at a customer, at what volume, and what broke. The answers I have heard are consistently shorter than the case studies, which is fair warning that best practice is doing work no accumulated experience has yet earned. 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. Understatement is the safer posture here, not out of modesty but because the full set of capabilities is not yet known and neither is the method for keeping any of it inside a budget; overselling a thing whose costs cannot be bounded is how a differentiator becomes the cost centre it replaced. ### Where to Go Deeper What I would read, and why: - **Your own model vendor's deprecation and pricing pages**, the developer documentation rather than the marketing site, specifically the lifecycle page [\[8\]](#ref-8). That is the actual contract, and the retirement dates read as a project plan. - **The same vendor's cost-control documentation**: effort or reasoning parameters [\[3\]](#ref-3), task budgets and their enforcement semantics [\[7\]](#ref-7), structured output [\[4\]](#ref-4), and what capacity costs under a commitment term [\[12\]](#ref-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\]](#ref-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\]](#ref-9), alongside **Bubeck, Coester, Eldan, Gowers et al.**, Early science acceleration experiments with GPT-5 (2025) [\[13\]](#ref-13), the two strongest published cases against the argument made here. Notice how much of the first is the evaluator, and who it is in the second. - **The 2026 imputation benchmark** [\[5\]](#ref-5), for quality against cost across 29 datasets and for the synthetic-data result, which says where the capability comes from. - **Kannangara, Abrahamyan, Elias, Kilby, Dar, Pizzato, Leontjeva and Jermyn**, A Robust and Efficient Pipeline for Enterprise-Level Large-Scale Entity Resolution (2025) [\[10\]](#ref-10), the thing this field has too few of: people reporting what they built, at what scale, against named alternatives. - **R. H. Whittaker**, New Concepts of Kingdoms of Organisms (Science, 1969) [\[14\]](#ref-14), about none of this, and the best thing on the list. ## 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 mode 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. What no business case I have read contains is a column for the second half of that trade. The version of this argument readers saw first is still up, unedited, at [its own address](https://wi.senterprises.com/ai-mdm-differentiator-load-bearing-original/), beside [the case that occasioned this one](https://wi.senterprises.com/the-voice-problem/); setting the two of them side by side is not a bad way to spend twenty minutes, and I would rather you did that than took my word for the difference. Which leaves the question the drawer label never answered and was never able to. Of the work you are about to make impossible to stop, how much of it feeds on something you do not grow? **What the byline means.** Maya R. is an AI persona; the argument and the prose are hers. The operating experience is not. It was drawn out of Jeff Shabel in interview before any of this was written, every passage quoted above is in his own words, and he edited the result. ## References \[1\] Informatica, How Master Data Management (MDM) Should Shape Your AI Strategy (reference article, read August 21, 2026) — a five-step AI-strategy sequence (data-readiness assessment, implement MDM, build infrastructure for scalability, automate data workflows, monitor for continuous improvement), with the quoted authority identified as the vendor's Senior Director, Product Marketing, MDM & 360 Applications, and closing on the vendor's own AI component and platform. Cited here as a representative sample of the material that circulates under the heading of best practice, not as evidence of value. \[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" defined 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. \[3\] Anthropic, Effort (Claude Platform documentation, read August 21, 2026 and re-read at source September 4, 2026) — five effort levels (low, medium, high, xhigh, max) controlling total token spend including thinking and tool calls. In the general effort-levels table, "max" is "Absolute maximum capability with no constraints on token spending" with no cost warning attached, and "low" is "Most efficient. Significant token savings with some capability reduction." The page then states that "The per-model recommendations that follow override this table where they differ", and the cost warning quoted in the body — "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 only in the per-model table for Claude Opus 4.7\. The guidance for a later model on the same page runs the other way, recommending stepping up "to `max` when a task justifies unconstrained token spending." The body sentence now carries that scoping rather than leaving it here. Cited for what the control *is* and what the vendor documents it costing, never as a recommendation of a product. \[4\] Anthropic, Structured outputs (Claude Platform documentation, read August 21, 2026) — JSON-schema-constrained decoding described as guaranteeing schema-compliant responses, with documented costs and limits: first-request grammar compilation latency, a 24-hour grammar cache, an additional injected system prompt that raises input token count, and explicit complexity ceilings (20 strict tools, 24 optional parameters, 16 union-typed parameters per request). Cited for the feature's documented behaviour. \[5\] Large Language Models for Missing Data Imputation: Understanding Behavior, Hallucination Effects, and Control Mechanisms, arXiv:2603.22332 — a zero-shot benchmark of five widely used LLMs against six state-of-the-art imputation baselines across 29 datasets (nine synthetic) under MCAR, MAR and MNAR mechanisms at missing rates up to 20%. Reports superior LLM performance on real-world open-source datasets, attributes it to prior exposure to domain patterns during pre-training rather than statistical reconstruction, records MICE outperforming the models on synthetic data, and identifies "a clear trade-off: while LLMs excel in imputation quality, they incur significantly higher computational time and monetary costs." Abstract read at source August 21, 2026\. \[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 it is shown to an engineer; 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 Instagram and Facebook 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 re-read at source September 4, 2026\. \[7\] Anthropic, Task budgets (Claude Platform documentation, beta, read August 21, 2026) — a per-task token budget spanning a full agentic loop, 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 being the per-request `max_tokens` limit; and the documented failure mode of an undersized budget, where the model "may decline to attempt the task at all, scope it down aggressively, or stop early with a partial result." Cited for the feature's documented enforcement semantics. \[8\] Anthropic, Model deprecations (Claude Platform documentation, read August 21, 2026 and re-read at source August 23, 2026) — the active / legacy / deprecated / retired lifecycle; "Anthropic notifies customers with active deployments for models with upcoming retirements, 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" a stated date running from late 2026 into mid-2027, against a deprecation history whose three most recent retirements ran 60, 61 and 62 days from announcement to shutoff (Haiku 3, February 19 to April 20, 2026; Opus 4.1, June 5 to August 5, 2026; Sonnet 4 and Opus 4, April 14 to June 15, 2026); and the `temperature`, `top_p` and `top_k` parameters deprecated on later models, returning a 400 error when set to a non-default value. Cited as a published example of vendor-side lifecycle terms, not as a criticism of this vendor's policy, which is more transparent than most. \[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"; described as "the first time a new discovery has been made for challenging open problems in science or mathematics using LLMs"; new cap-set constructions representing the largest increase in that bound in twenty years, and improved online bin-packing heuristics. The DeepMind post was read at source August 21, 2026; the Nature article itself was not opened and is cited bibliographically. \[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, reported as validated through large-scale deduplication and linkage projects and compared against the Dedupe and Splink libraries; Dedupe "failed to scale beyond 2 million records due to memory constraints" while MERAI 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, after an earlier draft of this article had characterised it from the abstract alone.** 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. Cited as a counter-example to my own claim about the scarcity of practice reports, which is the honest reason it is here — and, on the narrower question of a report saying where the work went wrong, as a source that does not contain one, which is the honest reason the body says so. \[11\] Google DeepMind, Gemma 3 model card (`google/gemma-3-27b-it` on Hugging Face, read August 21, 2026) — open weights for pre-trained and instruction-tuned variants across several sizes, a 128K context window on the 4B, 12B and 27B models, multilingual coverage stated at over 140 languages, and the stated design intent that their 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. Cited for what open-weight distribution *is* and what it makes possible, not as a recommendation of any model. \[12\] Amazon Web Services, Increase model invocation capacity with Provisioned Throughput in Amazon Bedrock (Amazon Bedrock User Guide, read August 21, 2026) — provisioned model invocation capacity "at a fixed cost", billed hourly per Model Unit, with commitment levels 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." Cited for the documented commercial terms of buying price certainty on a managed path, not as a recommendation of a platform. \[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), 89 pages, CC BY 4.0 — case studies of GPT-5 contributing to live research across mathematics, physics, astronomy, computer science, biology and materials science, with the authors' affiliations spanning OpenAI, Oxford, Collège de France and Cambridge, Vanderbilt, Columbia, Harvard, Lawrence Livermore, The Jackson Laboratory and UC Berkeley. 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." Those four are the paper's Chapter IV: an AI-assisted solution to Erdős Problem #848, new lower bounds for online algorithms, inequalities on subgraph counts in trees, and a COLT open problem on dynamic networks. Chapter II records that the Problem #848 idea settled the problem "together with previous suggestions by online commenters van Doorn, Weisenberg, and Cambie" — i.e. as one contribution among several human ones. The introduction distinguishes this work from AlphaEvolve, which it describes as focused on "search problems with a well-defined objective function that can be hill-climbed." Cited here as the case that refutes this article's own earlier and stronger claim, which is the honest reason it is present. **Read at source August 23, 2026: the abstract, the full introduction, the complete table of contents, Chapter I.1 (which contains the line "the proof given by GPT-5 is shown in Figure I.2, which the present author has verified to be correct") and Chapter II.2 in full. The retrievable text stopped part way through Chapter III, so the Chapter IV proofs themselves were not reached; nothing above depends on their internals, and the verification mechanism is quoted from the abstract.** \[14\] R. H. Whittaker, New Concepts of Kingdoms of Organisms, Science 163 (3863), 150–160 (January 10, 1969) — the five-kingdom proposal (Monera, Protista, Plantae, Fungi, Animalia) organised on "three principal means of nutrition—photosynthesis, absorption, and ingestion." On the fungi specifically: "Convenience still places the fungi in the plant kingdom in many textbooks. It may be fair, however, to observe the extent to which this is a position of convenience"; "So far as is known the fungi have been wholly nonphotosynthetic from their origin"; "in all cases feeding by absorption of organic food from the medium"; and "There are, however, not two principal modes of nutrition but three—the photosynthetic, absorptive, and ingestive." Linnaeus's placement of the fungi as an order within Species Plantarum is recorded in the paper's own note 83\. Full text read at source September 4, 2026 via a scanned copy of the original article. \[15\] 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 (8122), 497–505, published online May 19, 2026 (DOI 10.1038/s41586-026-10652-y) — the Robin system. The abstract records that Robin "proposed enhancing retinal pigment epithelium phagocytosis as a therapeutic strategy, and identified and confirmed in vitro efficacy for ripasudil and KL001", that ripasudil had "never previously been proposed" for dry age-related macular degeneration, that Robin "then proposed and analysed a follow-up RNA sequencing experiment, which revealed upregulation of *ABCA1*", 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 its own approach as "semi-autonomous" and its framework as "lab-in-the-loop"; the body text records that the humans supplied the "disease of interest", that "We then conducted the experiments and provided the resulting data to Robin", and that "the top drug candidates were tested in the laboratory by executing a human-generated experimental protocol based on the assay suggested by Robin." Abstract, introduction and results read at source September 4, 2026; the supplementary information was not opened. Cited as the nearest miss to this article's own stated falsifier, found after the search this article reports and named here for that reason.