> ## 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. # Putty, Not Body Panels: Building AI into Master Data Without a Strategy Behind It - URL: https://wi.senterprises.com/articles/ai-mdm-putty-not-body-panels/ - Published: 2026-10-07T08:00:00.000Z - Updated: 2026-11-06T03:11:24.000Z - Description: Building AI into master data without a strategy behind it shows first in where the model sits. Keep it out of every stage's default flow and use it as a measured backstop for the records standard processing cannot resolve, or it becomes a cost on every record for as long as the feed runs. - Author: Jeffrey Shabel - Tags: MDM + AI, AI-Augmented MDM Strategy & Value, 2026, October 2026, 2026-W41, AI: Central, #wi-art_01KVZKVTFN9WN9HC6XGZKJ5ENT *Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary* Here is a quick test of whether there is a strategy behind an effort to build AI into master data management: look at where the model sits. An effort without one does not show first in a missing document. It shows in the pipeline. When nobody has decided what the model is for, it ends up in the default path: every record in the feed passes through it, because that was the easiest place to put it, and the cost, the latency and the dependency arrive with every record from then on. When somebody has decided, the model sits to one side of the flow, takes only the records the ordinary machinery cannot resolve, and every call it makes is counted. Most of what is written about AI without a strategic foundation treats the foundation as something an organisation has or lacks before it starts, and lists the symptoms of lacking it: projects abandoned, pilots that never reach production, data that turns out not to be ready. Much of that I agree with. My argument is narrower, and it is about architecture rather than governance documents. The foundation is a set of decisions about the pipeline, and the most consequential of them is whether any stage of a master data pipeline runs a model as part of its default flow. Here is the claim I will defend, and it is my own position, not a reading of the literature. No stage of a master data pipeline should run every record through a model by default. By a model I mean a call to a hosted model priced by the token, not the trained matching and scoring engines a master data platform already runs as part of its own processing. Standard processing should come first, in ingestion, and should clean, standardise and de-duplicate as much as is practical. A model belongs behind it as a backstop for the records that need more, with its use measured, tracked and controlled. That is not a claim that AI has no place in master data management. It is a claim about where the place is. This piece starts where an earlier one stopped. [*Reinforce Is the Wrong Word*](https://wi.senterprises.com/articles/mdm-ai-roadmaps-reinforce-is-the-wrong-word/) argued that an AI roadmap is realistic only when it carries a token budget and a phase before full implementation that tests that budget. The question here is what gets built once the test has been passed. ## What the field blames One of the more careful accounts of why AI projects fail is not about models. James Ryseff, Brandon De Bruhl and Sydne Newberry at RAND interviewed sixty-five experienced data scientists and engineers. The report opens on an estimate it attributes to others, that more than eighty percent of AI projects fail [\[2\]](#ref-2); its weight is in the interviews. The root causes they list are a problem misunderstood or miscommunicated, too little of the right data, a focus on the newest technology instead of the problem, too little investment in the infrastructure that manages data and deploys models, and problems the technology cannot solve [\[2\]](#ref-2). Four of the five are about decisions made before any model is chosen, and the fourth is about pipelines. Gartner's version is better known, and it is a forecast rather than a finding: in February 2025 it predicted that most AI projects unsupported by AI-ready data would be abandoned by the end of 2026, and it publishes no method for the prediction [\[1\]](#ref-1). The sentence worth keeping from that release is the one with no number in it: "AI-ready data is not 'one and done'" [\[1\]](#ref-1). Readiness is a property of the data management practice, renewed for each use, not a state the data reaches once. Both sources describe the missing foundation from outside, as a cause of failure that can be counted in abandoned projects. Neither says where, in a pipeline, the absence becomes a cost. That is the question for master data, because a master data pipeline handles every record the enterprise holds about its customers, suppliers, products and people, again and again, and a decision about what happens to one record is a decision about what happens to all of them. Both also take the foundation as given or missing at the outset. From the inside, half a year into such an effort, what it looks like turns on whether the foundation was being built during those months: > It wholly depends upon whether we’re building the foundation as part of the effort during those six months or if everyone has been flying by the seat of their pants, solving their own problems in a vacuum. > > If the former, the strategic foundation has been established, tested, deployed, communicated and standardized throughout the Enterprise. If the latter, it looks like a mess because that’s what it is. That is where I part from the framing above. "Without a strategic foundation" is not a starting condition. A foundation can be built inside the effort, in the same months as the first pipelines, and the list of what that involves is specific: established, tested, deployed, communicated, standardised across the enterprise. Every item on that list is something a team does, not something it either has or lacks. Absence at six months is therefore the result of choices made during those six months, and the choice that matters most is the one each team makes alone when nobody has made it for them. A team solving its own problem in a vacuum puts the model where its own problem is. Repeated across teams, that is how a model ends up in the default path of a pipeline nobody designed as a whole. What the mess looks like differs from one estate to the next; the mechanism is the same, and it is enough to recognise one. ## The case for a model in every record's path That leaves the design question, and the case against my position on it is strong. It deserves to be stated at its strongest before I argue with it. A disclosure first, because what follows assesses vendors' products, including the one we deploy. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, a licence sale we refer earns us a referral fee from the vendor, and our services revenue depends on this category of software being bought at all. That interest runs toward praise of Profisee and of the category, so weigh anything favourable I say about either below my criticism of them. Tamr competes with Profisee, which gives me a reason to be hard on it; discount my criticism of it accordingly. Snowflake's data platform competes with the Microsoft platform Profisee is aligned with, which gives me the same reason, and the same discount applies. The model vendors' pages below are cited for their prices, not assessed. The research case begins with Avanika Narayan and her colleagues, who cast five enterprise data tasks, entity matching and error detection among them, as prompts to large foundation models and found that "large FMs generalize and achieve SoTA performance on data cleaning and integration tasks, even though they are not trained for these data tasks" [\[3\]](#ref-3). Ralph Peeters, Aaron Steiner and Christian Bizer, testing newer models on entity matching benchmarks, report that "the best LLMs require no or only a few training examples to perform comparably to PLMs" fine-tuned on thousands, and that LLM-based matchers "exhibit higher robustness to unseen entities" [\[4\]](#ref-4). That second finding is the one that matters for a pipeline. A rules engine is brittle in exactly the places the feed is new: a supplier who formats addresses differently, a product line nobody wrote a rule for. A model that copes with the unseen case is an argument for putting it where unseen cases arrive, which is ingestion. The cost objection has a research answer too. Meihao Fan and colleagues set out to make language-model entity resolution cheaper by batching the questions put to the model and choosing the demonstrations carefully, and found that "batch prompting is very cost-effective for ER" compared both with fine-tuned smaller models and with LLM methods using hand-designed prompts [\[5\]](#ref-5). The vendors have built on all of it. Tamr describes mastering that combines "human feedback from data curators with pre-trained machine learning (ML) models and semantic comparison with large language models (LLMs)" [\[6\]](#ref-6). Snowflake's AI\_EXTRACT function "lets you extract structured information, such as entities, lists, and tables, from text or document files" from inside the database [\[7\]](#ref-7), which puts unstructured-to-structured extraction one SQL call away from the load. Profisee's own AI assistant, Aisey, ships agent templates named "Parse Unstructured Data" and "Data Enrichment", and the page says it works by "automating where possible, escalating where human judgment is essential", with every change reviewable [\[11\]](#ref-11). Profisee's matching itself is described as "an ML-powered matching engine" that keeps "a human in the loop for manual review of inconclusive results" [\[12\]](#ref-12). Put that together and the case for a model in every record's path is not hype. Models match well with little training, they cope with records no rule anticipated, batching and careful prompting bring the price down, and the platforms make the call easy. If the variety of the feed is the hard problem, the model is the tool built for variety, and the place variety arrives is the front of the pipeline. ## All of them From here the argument is my own, a rule I hold rather than a finding the sources report. The sharper question is which stages of a master data pipeline should never run a model. My position goes further than the question expects: > All of them. I can’t see a compelling reason to run literally everything in an MDM pipeline through a model. Models are an entirely different animal from ‘standard’ data flow pipelines. There’s no reason to run every record through a model. "All of them" is about the default flow, not about the model's existence. Read with the build shape set out below, it is a rule about what runs for every record: no stage of the pipeline should send every record to a model as a matter of course. The model can still be called. It is called for a reason, by a rule, for a record that needs it. The rule is not a hedge against a hypothetical. Asked for a case, I can point to an organisation I have worked with that began by adding AI to everything in its pipelines: > Then they, predictably, outran their budget almost instantly. The company then overreacted and cut AI usage to the bone. There needs to be a happy medium where AI is used sparingly, but effectively and not as a panacea. That is both errors in one effort. The first is the default flow this section argues against: a model in the path of everything, paid for on everything. The second is the overcorrection, the same error in the other direction: an overreaction that cut AI usage to the bone, where the first effort had put it everywhere. The happy medium is what "measured, tracked and controlled" is for: model use that is counted and governed, not switched on for every record or cut to the bone. It is the putty again, used sparingly but where it works. The reason for the rule is in the phrase "an entirely different animal". A standard data flow, whether it parses, standardises, validates against reference values or matches on rules, behaves the same way every time it meets the same input, costs what its infrastructure costs whether it processes a thousand records or a million, and can be tested once and trusted until somebody changes it. A model call has a price per token set by a vendor, a latency outside the pipeline's control, an output that can vary between runs, and a dependency on a service that can change under it. Put that inside a stage that runs for every record and the stage inherits all four properties for every record. The animal is different, and it should be fed differently. The counter-position some practitioners raise is the one the research above supports best: use the model to extract structure from unstructured sources as part of ingestion. The objection to it is the meter: > I know some people will say use models to do structured data extraction from unstructured data as part of an ingestion pipeline. My position is, you can do what you want, but now you’ve added a token cost to every record you ever ingest in the future—even if you’ve ingested an identical record before or processed an identical JSON string before. Extraction in ingestion is a design a team can choose, and Snowflake and Profisee both make it easy [\[7\]](#ref-7)[\[11\]](#ref-11). The objection is to what the design commits the pipeline to. A master data feed is not a one-off migration; it runs every day or every week for the life of the platform, and much of what it carries is what it carried last time: the same supplier record resent, the same customer extracted again because a source system cannot tell what changed. A model in the ingestion path charges for each of them as if it were new, because, to the model, it is. ## What caching and batch pricing change The obvious reply is that the vendors have already solved this, and it deserves a careful answer because it is partly true. Prompt caching is real and the discounts are large. Anthropic prices a cache read for most models at "0.1 times the base input tokens price", lower for some [\[8\]](#ref-8), and OpenAI says cached input tokens are "discounted up to 95%" [\[14\]](#ref-14). Batch processing halves the price again: Anthropic charges batch usage "at 50% of the standard API prices" [\[9\]](#ref-9), OpenAI offers a "50% cost discount compared to synchronous APIs" [\[10\]](#ref-10), and Microsoft's Azure OpenAI batch service runs "at 50% less cost than global standard" [\[13\]](#ref-13). Anthropic adds that the caching and batch discounts "can stack" [\[9\]](#ref-9). Taken with the batching research [\[5\]](#ref-5), a team that builds carefully can make a model in the ingestion path much cheaper than its list price. What the documentation says about how the discounts work matters as much as their size. A cache is keyed on the prompt's prefix: Anthropic's cache "references the entire prompt", tools, system prompt and messages in order, up to the point marked for caching [\[8\]](#ref-8), and OpenAI's reuse "requires the entire rendered prefix to match" [\[14\]](#ref-14). What a cache saves on a pipeline is the repeated part, the instructions and the schema placed in front of every record. The record itself comes after the prefix, and a new record is new input. The cache is also short-lived: five minutes by default at Anthropic, with a one-hour option at extra cost [\[8\]](#ref-8), and thirty minutes after last use on OpenAI's newest models, or up to a day on OpenAI's extended retention for earlier models [\[14\]](#ref-14). A supplier record resent next week finds no cache waiting for it. And both vendors' cache discounts are on input [\[8\]](#ref-8)[\[14\]](#ref-14); the structured output the extraction exists to produce is paid for every time. So caching and batching lower the rate. They do not change what the rate is multiplied by, which is every record the pipeline ever sends. The only way to stop paying for an identical record is to recognise it as identical before it reaches the model, and that is a standard data operation: a hash, a comparison with what was loaded last time, a de-duplication pass. The pre-checks do arrive, but late: > Then you get into caching and preemptive checks as a reaction to the insertion of the model. I suggest trying to think ahead and optimize models out of pipelines as much as possible. Model usage should be measured, tracked and controlled instead of part of the default flow. The pre-checks are good engineering. My objection is to their order. When they are built after the model has gone into the path, they are a reaction: a team discovers its token bill, then bolts standard processing back on in front of the model to stop paying for records it should never have sent. Built first, the same checks are simply the pipeline, and the model never sees the records they resolve. The work is nearly the same either way. What differs is whether the model's share of the flow was designed or discovered. De-duplication is the clearest case, and it has a second payoff. Applied at batch and source level, before anything downstream, it reduces how many records reach any AI process at all, which makes the master data platform a way of spending fewer tokens, not a reason to spend more, as [*Proving the Platform Is Delivering*](https://wi.senterprises.com/articles/proving-the-platform-is-delivering/) argues. Running every record through a model first and mastering afterwards pays the per-record price on the very duplicates mastering exists to remove. ## Putty, not body panels If no stage runs a model by default, the question that was asked in the first place remains: once the token budget has been tested, what does the build actually look like? Real development starts there, and its order is not universal: > That’s when the real development begins and it depends upon the needs of the client. Ideally, we would integrate pre-processing with standard techniques as an initial pass and then an AI ‘backstop’ for those that need extra processing into the data ingestion process. Cleaning and standardizing the data as much as practical before it reaches the MDM system allows Profisee, and other products in its niche, to focus on the Mastering process. There is no numbered recipe in that, and there should not be one in an article either, because the order of work on a real estate is set by what that estate needs. What it gives instead is a shape, and the shape has three parts. Standard techniques make the first pass. A model stands behind them as a backstop, only for the records that pass through the first pass unresolved. And both live in ingestion, ahead of the master data platform, so that the platform receives data that has already been cleaned and standardised as far as was practical, and can spend its effort on what it is for: matching, survivorship, mastering. Some feeds cannot be standardised much before they arrive, and some estates will not fund the work, which is why the shape is an ideal and the cleaning goes only as far as is practical. The image that carries the whole argument is a bodyshop's: > I just want to reiterate, because it’s crucial to making AI work for the business, that AI should be used like putty instead of body panels. It should handle exceptions where possible. Extracting data from unstructured sources is a valuable skill, but it is also expensive and should be used sparingly and combined with model-fit testing and prompt engineering to optimize token usage. Body panels are the structure: they give the car its shape and carry the load, and every car has them. Putty fills the dents the panels left. It is applied where it is needed, shaped to the gap, and sanded back, and a car built mostly of putty is a car nobody should drive. In a master data pipeline the panels are the standard processing that every record passes through, and the model is the filler for the records the panels could not shape. Unstructured extraction is the case the metaphor is most often asked to excuse, because it is genuinely valuable and genuinely hard to do any other way. It is also the most expensive thing a model is asked to do on a pipeline, which is why it should be used sparingly and never without two companions: a test of which model fits the job, and prompts engineered to spend as few tokens as the job allows. Which model fits can only be settled by testing on the organisation's own records; smaller current models are candidates alongside older ones, and [*Costing the Promise*](https://wi.senterprises.com/articles/ai-mdm-business-case-playbook/) priced that comparison as a line in the business case. Nor does the shape contradict the Deep Dive on business cases, *The Line That Moves After Approval*, which argued that pre-processing has to be priced both ways because the comparison can invert where the rules are many and brittle or the volumes are low. Putty first and panels second is sometimes the cheaper build. The point is that the comparison is made, on the records, before the design is fixed, not discovered afterwards in the bill. Put together, the shape is two flows rather than one. In the first, the model is in the path and every record pays for it. In the second, the path is standard processing end to end, and the model is a side branch that only some records take. ![Two pipelines. Left: every record passes through a model in ingestion before MDM. Right: standard pre-processing feeds MDM and only exceptions take a measured side path to an AI backstop. Every label is written out below.](https://wi.senterprises.com/assets/diagrams/FIG009_MAI_Where_The_Model_Sits_v1_0.png) Figure 1: The same sources and the same master data platform, with the model in two different places. How many records take the side path depends on the estate. **Where the model sits: in the path of every record, or beside it** A note across the top reads: Concepts, not measurements: no count, share, price or threshold is shown. Below it, two panels side by side, each a pipeline running down the page from **Source systems** at the top to **MDM: matching, survivorship, mastering** at the bottom. **Left panel, headed “Model in the default flow”.** Between the sources and MDM is a single box, **Ingestion: every record sent to a model**. The arrow into it is labelled **Every record, every load**. A note beside the box reads **Token cost on every record, identical ones included**, and under that, **Caching and pre-checks added afterwards, as a reaction**. **Right panel, headed “Model as a backstop”.** Between the sources and MDM is a highlighted box, **Ingestion: standard pre-processing**, listing **standardise · validate · de-duplicate**. The main arrow continues down from it to MDM. A dashed side arrow labelled **Exceptions only** leaves the pre-processing box for a box to its side, **AI backstop**, tagged **Measured · tracked · controlled**, and a dashed arrow labelled **Resolved** returns from it into MDM. A band under both panels reads: **Putty, not body panels: the model fills the gaps the standard flow leaves.** A side branch is only measured, tracked and controlled if the pipeline makes it so, and three things do, none of which depends on a particular number. The branch needs a rule for entry: a record goes to the model because a named check failed, not because it arrived. Where the model is asked to decide, it should be asked how sure it is, the answer thresholded, and the weak cases routed to a person, because a model frequently carries a signal of its own uncertainty that a plain pipeline simply discards, though that signal is to be trusted only after it has been tested against the organisation's own records, alongside the test that settles which model fits. And the branch needs its own counts, kept beside the flow counts the platform already keeps: how many records took it, why, and what they cost. A side path whose traffic is counted shows the moment it starts turning into the main road. A gate that is written down and not enforced is a suggestion, as [*Every Generation Moved the Work*](https://wi.senterprises.com/articles/ai-master-data-every-generation-moved-the-work/) shows from the history of machines on master data; the entry rule for the branch has to be one the pipeline enforces. ### What to ask of a design before it is built These are not steps in an order. The order depends on the estate. They are questions to put to any design that puts AI into a master data pipeline. **Does any stage send every record to a model?** If it does, the design has chosen a token cost on every future record, identical ones included. That can be a deliberate choice; it should not be a default. **What runs before the model?** Standardisation, validation against reference values and de-duplication should come first, in ingestion, as far as is practical. Every record they resolve is one the model is never paid to see. **What sends a record to the backstop?** A named rule, not arrival. If the answer is "everything the rules did not handle", the rules are the design, and the backstop's traffic measures how good they are. A record the rules wrongly pass never reaches the backstop at all, and that is a defect in the rules, not a case for sending every record to the model: the rules are the design, they get tested like any other code, and mastering downstream is the second look. **Is the model's share counted?** Records routed, reasons and cost, kept as a series. If nobody can say what share of the flow takes the side path, the side path is not controlled. **Were the pre-checks designed or added?** Caching, hashing and comparisons with the last load built in from the start are the pipeline. Added after the first bill, they are a reaction to having put the model in the wrong place. **Was the model fitted?** Extraction from unstructured sources should be used sparingly, after a test of which model does the job on the organisation's own records and with prompts engineered for the token budget the validation phase set. ## Strategy is where the model sits The phrase "AI without a strategic foundation" makes the problem sound like a missing document, something a steering committee could write in a quarter and then hand to the teams. The sources that study failure point somewhere more concrete: at the problem being misunderstood, at the data, at the pipelines [\[2\]](#ref-2), and at a readiness that is never finished [\[1\]](#ref-1). In a master data pipeline those concerns meet in one decision, repeated for every stage: does every record go through the model, or only the ones that need it? A strategy, in this sense, is that decision made once, for the whole pipeline, before the teams make it separately. It can be made during the effort, in the same months as the first build, and when it is, six months in, the foundation has been established, tested, deployed, communicated and standardised. When it is not, each team puts the model where its own problem is, and the pipeline acquires a meter on every record without anyone having chosen one. The research shows that models can do much of what the pipeline needs. The documentation shows that their price can be brought down. Neither changes the arithmetic of a cost paid per record for the life of a feed. Standard processing is the panels. The model is the putty. Build the car from panels, and keep the putty for the dents. ## References \[1\] Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk," press release, 26 February 2025\. Read 2026-10-06 through a rendering fetch; not stored locally. Cited for the prediction (paraphrased in the body as a forecast made in February 2025: "through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data") and the "not 'one and done'" sentence, quoted in the body. The forecast's window closes in 2026 and it is not a measurement of what happened; nothing in the article rests on its figure. The release attributes the sixty-three percent to "a survey by Gartner" and separately mentions a survey of 1,203 data management leaders in July 2024; it publishes no method for the prediction. \[2\] James Ryseff, Brandon F. De Bruhl and Sydne J. Newberry, *The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI*, RAND Corporation, RR-A2680-1, 13 August 2024\. Read 2026-10-06 through a rendering fetch of the report page; not stored locally. Cited for the five root causes and for the attributed estimate the report opens on ("By some estimates, more than 80 percent of AI projects fail—twice the rate of failure for information technology projects that do not involve AI"), which the report does not claim as its own finding; its findings rest on interviews with 65 experienced data scientists and engineers. \[3\] Avanika Narayan, Ines Chami, Laurel Orr, Simran Arora and Christopher Ré, "Can Foundation Models Wrangle Your Data?", arXiv:2205.09911, May 2022, revised December 2022\. Read 2026-10-06 (the paper PDF, and the abstract page at ) through a rendering fetch; not stored locally. Cited for the sentence quoted in the body (abstract) and for the five task names, "entity matching, error detection, schema matching, data transformation, and data imputation" (paper, Section 4.2). \[4\] Ralph Peeters, Aaron Steiner and Christian Bizer, "Entity Matching using Large Language Models," Proceedings of the 28th International Conference on Extending Database Technology (EDBT 2025), Barcelona, March 2025\. Read 2026-10-06 through a rendering fetch of the University of Mannheim announcement; the arXiv abstract page (arXiv:2310.11244) refused the fetch. Cited for the two findings quoted in the body. \[5\] Meihao Fan, Xiaoyue Han, Ju Fan, Chengliang Chai, Nan Tang, Guoliang Li and Xiaoyong Du, "Cost-Effective In-Context Learning for Entity Resolution: A Design Space Exploration," arXiv:2312.03987, December 2023 (ICDE 2024). Read 2026-10-06 (abstract) through a rendering fetch; not stored locally. Cited for the batch-prompting finding quoted in the body. \[6\] Tamr, "About Tamr's AI-Native Approach," Tamr Cloud documentation. Read 2026-10-06 through a rendering fetch; not stored locally. Vendor page (a Profisee competitor). Cited for the sentence quoted in the body. \[7\] Snowflake, "Extracting information from documents with AI\_EXTRACT," Snowflake documentation. Read 2026-10-06 through a rendering fetch; not stored locally. Vendor documentation. Cited for the sentence quoted in the body. \[8\] Anthropic, "Prompt caching," Claude Developer Platform documentation. Read 2026-10-06 through a rendering fetch; not stored locally. Cited for the cache-read multiplier (0.1x for most models; the page lists lower multipliers for some, e.g. 0.05x and 0.025x), the prefix rule, the five-minute default and one-hour option, quoted or stated in the body. \[9\] Anthropic, "Batch processing," Claude Developer Platform documentation. Read 2026-10-06 through a rendering fetch; not stored locally. Cited for the batch price and the sentence on stacking with caching, quoted in the body. \[10\] OpenAI, "Batch API," OpenAI API documentation. Read 2026-10-06 through a rendering fetch; not stored locally. Cited for the discount quoted in the body. \[11\] Profisee, "Aisey: The AI Assistant Redefining Enterprise MDM," product page. Read 2026-10-06 through a rendering fetch; not stored locally. Vendor page (the vendor we partner with). Cited for the agent-template names and the two phrases quoted in the body. \[12\] Profisee, matching and survivorship solutions page. Read 2026-10-06 through a rendering fetch; not stored locally. Vendor page (the vendor we partner with). Cited for the two phrases quoted in the body. \[13\] Microsoft, "Getting started with Azure OpenAI batch deployments," Microsoft Learn, updated 5 June 2026\. Read 2026-10-06 through a rendering fetch; not stored locally. Cited for the batch price quoted in the body. \[14\] OpenAI, "Prompt caching," OpenAI API documentation. Read 2026-10-06 through a rendering fetch; not stored locally. Cited for the discount, the prefix rule and the retention periods (thirty minutes after last use on GPT-5.6 and later; the 24h setting for earlier models "can retain them for up to 24 hours"), quoted or stated in the body.