←  Library
Essay 21

The delta nobody budgeted.

Keeping a system matched to a moving world has never been anyone’s job.

Data foundations, applied to AI systems

Breaks at construct → representation, then the return leg  ·  meaning

Chaitanya Ramineni, PhDSeptember 30, 202622 min read
Cover illustration for The delta nobody budgeted.

The special-education compliance director was the only person who could turn a student’s status into a billing code.

The student information system carried the broad designation, which is what the state’s reporting asks for. A claim needs something finer than that: which service was actually provided, at what frequency, by whom, in that week. Getting from one to the other took a derivation she made from the service records, and no field in either system held it.

Then she left.

The question arrived not long after, from the chief executive, who suspected that the year before the network had not billed correctly, and that money it was owed for services it had actually delivered had stayed with the state. The network was budgeting deliberately for special-education and English-language services. It hired for them and it protected the time to deliver them well. What it was not doing reliably was recovering the reimbursement, so the full cost of those services sat in its own budget and the revenue that should have offset them did not arrive.

Answering that question meant reconstructing what she had been maintaining.

She had not written the mapping down. A document would not have been enough anyway, because the mapping did not hold still. It moved when a student’s services changed, when the state revised its designations, and when the codes themselves were reissued. She was holding the work of keeping that mapping current, which is a different thing from holding a fact, and it is the part a handover rarely captures.

Nobody budgeted for any of it. In the organizations I have worked in, nobody ever did, because the work has no name.

Nobody owns the transition

The systems in schools, clinics, campuses and nonprofits get set up once, and the hope is that the setup is done, so people can go back to serving the students, patients and families in front of them. The world those systems record does not stand still.

Budgets in these organizations cover the systems as they stand. The student information system, the electronic health record, the CRM, the warehouse, the licenses and the analyst all have line items. The work of getting from one configuration to the next has none. So the cost does not disappear. It moves to places that are not labeled as cost. Most of it is paid in labor, by whoever can bridge the old world and the new one, in hours that are rarely recorded as change work. Some of it can be paid in revenue, as the special-education case suggests: when nobody maintains the derivation behind a claim, money earned for services already delivered can stay with the payer. And some of it is paid in the record itself, as a trend line that breaks without announcing that it has. None of these appears in a budget as the cost of a change, so the change looks free.

A state reissues a definition. A funder changes a reporting template. A counselor leaves in March. A student demonstrates English proficiency on the state’s official test and comes off English-language status, and the record has to follow her. The vendor ships a release that renames a field. The year rolls over and the system archives what it was told to archive. Each of these opens a gap between how the world now works and how the system is configured, and most of them leave someone with three jobs: reconfigure the system, re-teach the people who enter the data, and re-map what was already recorded.

They do not all arrive on the same clock, either. A definition can be reissued every few years. In the network I worked in, a student had two or three internal assessment windows across the school year, which showed her progress against the network’s own goals. Her official status could change only after she demonstrated proficiency on the official test, on a schedule the state sets rather than the school. So the record had to carry two clocks for one student: an internal level that moved several times a year, and an official status that moved only when the state’s test said so.

  1. 01Reconfigure. The system has to be changed to match the new rule.
  2. 02Re-teach. The people entering data have to be told what changed, where, and who is responsible now.
  3. 03Re-map. What was recorded under the old rule has to be reconciled with the new one, or the comparison across years stops meaning anything without ever announcing that it has.

Together those three jobs are one recurring task: keeping the organization’s representation of the world synchronized with a world that keeps moving. Call it change maintenance. The name matters for a practical reason. Work without a name does not get a budget line, an owner, or a sentence in anyone’s job description. Change maintenance has had none of the three.

Ankit Saxena makes the same observation about ontology work in data teams. In his account it “was never missing. It was just never funded,” and the effort “always existed — as a wiki nobody updated, a data dictionary in someone’s laptop” (Saxena, Medium, July 2026). Change maintenance has the same history. What this essay adds is the clock: ontology records what the data means, and change maintenance is the work of keeping that meaning current each time the world moves.

Change maintenance, and the model inside it
Four kinds of change event, three jobs each, and one record that says what the boundary was. The model sits inside the loop, and is also one of the events that opens it.

I have watched this in a school network, a research university, a community behavioral-health agency and a national youth mental-health nonprofit. The change events differ. The three jobs do not. And in none of those organizations was there a person whose job was to absorb them. The work went to whoever was capable and present, on top of what they were already doing. That is the absorption pattern I described in The absorbed data role, and it is the same seat that carries everything in For the record.

The two essays split on where the gap sits. That one is about distance: the spreadsheet an owner trusts and the record the institution holds, two versions of the same thing at the same moment. This one is about time: one system, and a world that keeps moving while the configuration stays where it was put.

An organization can live with a bad configuration for a while, because the people entering data notice when a field is wrong. A broken trend line is harder to live with, because every claim about change over time, to a funder, a board or a state, rests on it, and nobody entering data sees it break. In my experience the re-map is also the job that gets skipped first, because the other two have someone waiting on them and the re-map does not.

When the rule changes and the vendor has a roadmap

Follow one policy change from the state’s memo to the front desk. Most of the delay turns out to sit with the vendor rather than inside the organization.

The organization can only ask for the reconfiguration. The attendance codes live in a student information system that serves several hundred districts, and the change goes into a queue. It lands in the next release, or the one after. Meanwhile the state’s deadline does not move, and the staff at the front desk keep logging the old code because the new one does not exist yet in the only place they can enter it.

The gap between when the world changes and when your system can represent the change is a vendor’s roadmap, and you do not control it. It is the integration governance question from The contracts between systems pointed at time rather than at data: what the vendor owes you, and by when, is a term of the contract nobody wrote down. You are one customer among hundreds, your ticket is one of thousands, and the person who has to explain the delay to a superintendent is you.

What a model changes here is narrow and real. Given the policy memo, the system’s current configuration and the mapping you already hold, it drafts three things in one pass. The configuration specification to send the vendor. The old-to-new policy map, so the trend survives. And the one-page note that tells the front desk where the field is and who logs it. A person checks each. What used to be weeks of back-and-forth becomes three drafts a person can check line by line.

What it does not change is the release date. A model cannot move a vendor’s roadmap. It can make the interim survivable (a documented workaround, a holding field, an explicit note that these three months were recorded under the old definition); the queue stays the queue.

And one judgment stays human, permanently. Whether the new definition is comparable to the old one is a measurement question, not a mapping question. It is the question What is this system measuring? asks of an AI system, asked here of an attendance code. A model can produce a crosswalk between two code sets, and it can do more than that. It can read both definitions, name where the construct shifted, and propose the sensitivity check that would test whether the shift matters. What it cannot do is own the answer. Whether a trend spanning the boundary is a trend or an artifact is a claim the organization makes to a board, a funder or a state, and a claim has to carry somebody’s name. Get it wrong and the error is invisible, because the chart still renders.

What the rollover keeps

The year-end rollover arrives on a date everybody knows. The student information system closes the year, promotes students, ends enrollments and archives sections. The settings that decide what carries forward were chosen once, usually from the vendor’s defaults or by whoever ran the rollover the year before. After that they tend to run every year without anybody deciding them again, and when the person who chose them has left, nobody can say what they were chosen to protect.

So the rollover makes a decision about what the organization will be able to ask later, and it makes that decision silently. A field that was not set to carry forward does not disappear in any way that raises an alarm. It is absent from next year’s records. Nobody notices in September, because nobody needs it in September. The loss shows up years later. Someone asks, for example, whether students in a tutoring program came to school more often than students outside it. The field that marked who was in the program turns out to exist for the latest cohort and for no one before it.

Of the change events in this essay, the rollover is the one an organization can see coming, because it is on the calendar. In a larger organization it belongs to a director of systems, so the technical step has an owner. The decision inside it often does not. Which fields a question three years from now will need is a program and measurement question, and the person running the rollover is often not the person who will ask it. Large organizations tend to split the work the same way. The system change, the training and the definitions each have an owner, and the question that joins them, whether the trend still holds across the change, often has none. In a smaller organization there is no such director, and the work falls to whoever knows where the settings are, in the last weeks of a school year, on top of closing that year.

What changes the cost is a list made before the rollover runs. Call it the preservation list. A model given last year’s schema and this year’s can draft it: the fields that will not carry forward, the codes being retired, and the links between records that will break. A person then marks each item. Keep it, archive it with a map to what replaces it, or let it go on purpose. After the rollover, a short script checks that everything marked keep is still there. The list turns a silent loss into a decision somebody made and signed, and it becomes the rollover’s entry in the organization’s change log. When measurement arrives after the build asks the same question of a product that has no record to keep yet.

The daily version

The change events above arrive a few times a year and open a gap measured in quarters. One arrives every day and opens a gap measured in hours. It is the same delta at a shorter interval. The world moved at two in the afternoon, the record caught up at half past five, and what fell into the interval was everything the person could no longer recall.

The gap between what happened and what got recorded is the oldest version of this problem. A clinician sees a client at two and enters the note at half past five, after the last person has left, from memory, into fields designed to produce a report for the state. A teacher logs an intervention three days later. What gets written is what the form asks for, and what the form asks for is what someone outside needed counted.

A model sitting at that seam changes who writes the record and when. The person speaks or types a short note in her own words; the model drafts the structured entry in the system’s fields and codes; she corrects it and confirms. The form still gets filled. It gets filled on the day, by the person who was there, from what she observed rather than from what she can still recall at 5:30.

This pattern is already sold to solo mental-health practitioners as ambient note-taking, at $19 to $99 a month (Johnston, NPR, May 2026). The same reporting carries a caution that has to travel with it, and it should not be buried. On a YouGov survey it quotes, about 11 percent of Americans say they would be open to using AI in mental-health care and 8 percent say they trust it. On a KFF survey, about 77 percent are worried about how their health information would be stored and used by AI systems (same report). So the design has to answer that directly. The person stays the author of the record. The model drafts and the human signs. The data does not leave the organization’s contracted environment. Under those conditions the record becomes contemporaneous, and that matters more than any added sophistication.

And one thing becomes possible that has nothing to do with speed. Case notes, intake narratives and the box that says anything else you would like to tell us hold most of what a program knows about a person, and very little of it has been readable in bulk, so programs report the structured fields and lose the rest. A model can read that text and code it into a field. The coding holds up when subject-matter experts first validate a reference set by hand, and a person makes the final call on each case. What that does to the richness of what an organization can say about the people it serves is a bigger argument than this essay carries, and it needs its own piece.

What a model does with change work, and what it does not

One division of labor runs through all of this, and it is the same one For the record argues for at the other seam.

  1. 01The model proposes. It reads the memo and the configuration, or the note and the form, or the old schema and the new one, and it drafts the translation.
  2. 02A person confirms. Someone who knows the domain reads the draft, corrects it, and adds the exception the model could not know.
  3. 03Deterministic code preserves. The confirmed rule runs the same way every cycle and raises a flag when something stops fitting.

The first two steps come from When GenAI redesigned my dashboard, where the heading was AI proposes, human curates. What is added here is the third step, which keeps the proposal from dying on one person’s desktop. It is the gate pattern from Extending the gates: a model drafts, and code that cannot be talked around checks.

The third step, running the confirmed rule in code instead of asking the model again each time, tends to get skipped. There is now evidence of what goes wrong without it. Dmitry Ustimov gave an agent two legitimate definitions of the same measure, a tool for asking which was meant, and an instruction to ask. Across 51 attempts it never asked and never showed both values; it picked one and said nothing about the other. What fixed it was moving the disclosure out of the model: comparing both definitions at runtime and inserting the missing one before the answer reached anybody (Ustimov, Decision Spine, September 2026). A confirmed rule running in code is the same move at the seam this essay is about.

Change maintenance suits this division well, because a large component of it is translation. An old code set to a new one. A policy memo to a configuration. A spoken observation to a structured field. A schema to its successor. Translation is the part a model can now draft.

The rest of change maintenance does not get easier with a model. Deciding whether the new definition measures the same thing as the old one is measurement judgment. Deciding who owns intake coding now that the counselor has gone is organizational design. Getting the field built is dependency management. Persuading a staff already tired of changes to enter data a new way is change management. A model touches the translation component and leaves those four roughly where they were.

That is still a large gain. The translation component recurs on almost every change event, and the expensive part was never doing it once. It was that nobody had the time to write it down in a form a machine could run.

This is also where two problems nobody files under change work turn out to belong here. Missing data and inaccurate data have many causes. A form that is hard to use. A definition two people read differently. A workload that makes data entry the thing that slips. An extraction that failed quietly. But a recognizable share of them are old changes whose lineage was lost: something changed, nobody recorded what, and the residue is what shows up in the export years later. A field that is empty in every record entered before a certain date is empty because something changed on that date, and nobody wrote down what. A status code that means one thing in the fall and another during the spring campaign is two rules under one name, which is the failure The numbers don’t agree because the words don’t works through at length. A model can profile an export and list these: the fields that went empty on a certain date, and the codes whose meaning shifts with the season. It is simple work. In twenty years I have almost never seen an organization do it, because it takes a day and produces no report anyone asked for.

A model cannot move a vendor’s release date. It can argue about whether a redefined measure is comparable across the boundary, and it cannot own the answer. It drafts the document and does not maintain it. Anthropic’s own data team reports what untended documentation does to an analytics agent: offline accuracy drifted from about 95 percent at launch to about 65 percent over a month (Chang et al., Anthropic, June 2026). The maintenance does not disappear. It moves from reconstructing what a column meant every time somebody asks, to keeping one written set of rules current. Keeping the rules current is a much smaller job than answering the same question from scratch each time. It still has to be somebody’s.

The model is a change event too

So far the argument has been that the world keeps changing and a model can absorb the translation work that change creates. If the essay stopped there, it would read like a vendor’s pitch, because the model is now one of the things that changes.

The version you drafted your mappings with gets upgraded, or deprecated, or swapped out behind an API without notice. It behaves differently. Whether your confirmed translations still hold is not announced anywhere. For an organization with no data team, a model upgrade is indistinguishable from a vendor release. The one difference makes the model harder to manage: a vendor release comes with release notes and a date, and a model change often comes with neither.

So the thing bought to stop the organization absorbing deltas by hand arrives carrying one of its own, and a less legible one than the vendor’s.

The reason it is hard to see is structural. A 2026 validity study of generative-AI essay scoring reports its agreement statistics on 6,514 of the 13,032 argumentative essays it analyzed, written by students in grades six through twelve. Two runs of GPT-4o agreed with each other at a quadratic weighted kappa of about .97. They agreed with the adjudicated human score at about .52, and Gemini 1.5 Pro did about .05 better (Casabianca, McCaffrey, Johnson, Alper and Zubenko, arXiv preprint, March 2026; not peer reviewed, and the authors note that the models weighted basic writing quality more heavily than the rubric does, so the pair reads as a gap between reliability and agreement rather than as a score for the models). A model can be highly consistent with itself and still disagree with everything outside it, because those are separate properties.

That study measures one version against itself, so it cannot on its own tell you what happens across versions. It establishes the weaker and more useful thing. Version A can be near-perfectly consistent with itself, version B can be near-perfectly consistent with itself, and the two can still differ systematically from each other, because nothing in either one’s internal steadiness is anchored to an external standard. Internal consistency is not evidence of stability across a version change. That steadiness is what hides the change: each version looks consistent on its own, so watching the model’s outputs will not show that anything moved.

You detect it by holding something still outside it.

The instrument is small enough for a school to run. Keep a fixed set of real cases whose answers you already know (twenty rows an experienced person can vouch for) and re-run them whenever the model changes. If the answers move, the mappings need re-confirming before the next cycle writes anything to the record. That is an anchor set. Human scoring programs call the same check trend scoring, and the study above recommends it for language models: score the same set of responses in each scoring period, so that a change in the model is not mistaken for a change in the students (Casabianca et al., 2026). Extending the gates runs the same check on a public-data project: six finished panels are locked to known outputs, and if any of them changes, the build stops. An anchor set is that check, made small enough for a school to run.

And an anchor-set run is a change event like any other, so it leaves the same thing behind: the model version changed on this date, these reference cases moved, these mappings were re-confirmed, and this is what the trend can and cannot claim across that boundary. That is the same record a state’s redefinition leaves. The organization does not need a separate process for AI, because the change log it keeps for policy changes covers model changes too.

Healthcare governance has already specified a version of this, at a scale most of these organizations do not have. Thomas F. O’Neil III, a managing director at BRG, argues that when a tool updates its model or changes its logic, the organization has to be able to reconstruct what the tool produced at the time of a given patient encounter. That means tracking model versions, prompt versions and the configurations that affect output, and writing into the vendor contract that material changes get notified. The same report adds that the audit trail should preserve a chain of custody from generation through clinician review to adoption or rejection (O’Neil, quoted in Siwicki, Healthcare IT News, September 2026).

Two things differ here. The instrument above is twenty rows an experienced person can vouch for, because a school or an agency has no governance function to run the health-system version. And this essay proposes no separate regime for AI. The model upgrade goes in the same change log as the state’s redefinition, because to the person who has to answer for the trend they are the same kind of event.

It is also, for whatever it is worth, a discipline I already run on myself. The editorial standard behind this library caps a punctuation habit on the basis of how models write, and the rule carries its own instruction: re-check on the next model release. A rule written against a model has a shelf life. So does a crosswalk.

What to ask for

Three people can use this directly.

If you run a program, a school or an agency, stop treating change events as interruptions to the real work and start treating them as the recurring cost they are. Rory McDonald and Will Drover make this case for AI in large companies. An organization that treats a continuous process “as a string of episodes” fatigues its people. And “the work of tracking, translating, and triaging AI’s churn should be somebody’s actual job rather than a standing favor” (McDonald and Drover, MIT Sloan Management Review, September 2026). In a school or a clinic, AI is one stream of that change among several, and there is usually no AI unit to hand it to. Count the change events. In a normal year, how many times did a definition change, a vendor release land, a key person leave, or a year roll over? That number is the size of a job nobody holds.

Then point AI at the three jobs each event creates, in order: draft the configuration request, draft the note that tells the front desk what changed, and draft the old-to-new mapping. Have a person confirm each. The deliverable is a mapping that is written down, which means the next change starts from a record instead of from someone’s memory of what happened last time.

If you are the person who has been absorbing these, every change should leave behind a record of the boundary it created. That record is the change log: what changed, when, what it was mapped to, who confirmed it, and what the trend can and cannot claim across the boundary. The entry depends on the event. A policy change leaves a policy map, old code to new, with the name of whoever confirmed it, and a vendor release that renames a field leaves the same kind of map. A rollover leaves its preservation list. A model upgrade leaves an anchor-set run. When someone leaves, the entries she confirmed need a new name beside them, or they stop being confirmed by anyone. The change log belongs inside the file For the record asks for. It is the part of that file that deals with time: that essay’s crosswalk records what the organization’s data means across its systems, and the change log records what it meant across its years. A model will draft each entry from the memo and the schema. What it cannot do is decide whether the comparison holds. That judgment is the reason the role should exist, and it survives you only if it is written down.

And for whoever is evaluating a tool: ask what happens when the model changes. The question is narrower than whether the vendor has a governance policy: what happens to your confirmed mappings, how you would find out, and who re-runs the anchor set. A vendor who has not thought about it will tell you their model is stable. That is the answer of somebody who has only ever watched the model. Partnership is a handoff takes that conversation back to the purchase itself, where the seam between what the vendor supplies and what you supply is still open to negotiation.

When the chief executive’s question came, I tried to write the compliance director’s derivation down. I could not reconstruct it closely enough to codify, the reporting could not wait, and so I did what the organization had done before me. I relied on the number the new compliance director gave me.

She was maintaining her own sheet. She pulled what she needed out of the billing system and sent me the figures when a report was due. The claims went out and the dashboard showed a number. How that number had been arrived at lived in her sheet and in her working memory, and nowhere else.

The network had not solved the problem so much as rehired it. Whoever comes after her will start where I did, with a derivation to rebuild and no record of how the last person made it. And what the organization was depending on in the meantime was a spreadsheet, maintained by one person, holding a rule that nobody else could state.

Written September 2026 for the Analytic Bytes Library. No employer, client, authorizer or funder is named; every seat is described by role, and the compliance director, the billing question and the private sheet are from the author’s own experience. External sources were checked against their published pages between September 16 and October 1, 2026. The scoring figures are from Casabianca, McCaffrey, Johnson, Alper and Zubenko, arXiv:2603.19280, a preprint that has not been peer reviewed; the agreement statistics are on 6,514 of the 13,032 essays the study analyzed, and the two kappa values are read as a gap between reliability and agreement, not as a benchmark for the models. The survey figures are YouGov’s and KFF’s, as reported by Windsor Johnston for NPR. Thomas F. O’Neil III is quoted in Bill Siwicki’s reporting rather than its author. No figure is given for the cost of change maintenance, because no published source measures it.

Analytic Bytes
From fragmented to decision-ready.

Questions, pushback, or a problem that looks like this one? Write to chai@analyticbytes.systems.