Network operations and the person who owned the system’s configuration had two different absence numbers for the same month, and neither of them had made a mistake.
The student information system counted what it had fields for. A day was present or absent. The worksheet network operations kept, fed each week by the school ops staff who take attendance at the sites, carried what the system could not hold: the half-day suspension the system books as a full absence, the tardy that was never converted after somebody checked the sign-in sheet, the unexcused absence that became excused once a staff member called the family and found out what had happened. None of those were corrections to the system’s data. They were the things the system had no field to ask about.
The number was going into a report the chief operating officer had to sign, for the network’s authorizer. The figure network operations sent up did not match the one the system produced, and the person who owned the system’s configuration could not say which was right. It came to me, the analytics lead, to reconcile the worksheet against the configuration before anybody could sign anything.
Nobody in that exchange disagreed about what an absence is. They disagreed about which record held what had actually happened, and the more complete one was kept by a person, in a file the institution did not own.
That is not a failure of anyone’s diligence. The system was chosen because the state required it, and it was good at producing the report the state wanted. It was not set up to record that a suspension was half a day, or that a family had an explanation nobody had heard yet on Monday. The people came first. The system came second, for the record.
That order is correct, and I would not argue with it. When the mission is a person in front of you, the system that documents the encounter loses to the encounter every time. What it produces is an organization whose systems are good at the outside report and thin everywhere else. The people keep their own records in order to do the work. I have worked inside that kind of organization in K-12, higher education, community behavioral health and at a national youth mental-health nonprofit. This essay is about where that order leaves the systems, and what the people do in response. Then it asks what AI changes, when there is no budget to replace the system and no funded data role to run it.
Where the trust went
The systems in these organizations are kept for the record. I do not mean that every one was bought for that reason; a student information system or an EHR is bought to run the place. I mean that what gets funded, configured and maintained in it, and what the institution relies on it for, is the part that produces a report someone outside requires. The state’s enrollment census. The funder’s quarterly outcomes. The accreditor’s file. The compliance submission for a Certified Community Behavioral Health Clinic. The system is judged by whether that report comes out on time and in the required shape. It is not judged by whether a teacher can use it at three in the afternoon, and it was not configured with that in mind.
This is not a criticism of the people who set it up. Often they configured what the funder or the state required, with money from a grant that has since ended, and many of them have since left. What I want to hold on to is that the diagnosis usually gets this wrong. The usual reading is that the organization chose the wrong system or configured it badly. The reading I hold is that the system is doing what it was bought to do. Viral Gandhi describes the enterprise version: AI-enabled applications are converting systems of record into systems of action, and if the workflow redesign is not accompanied by governance, the risk is automating tasks without improving anything (Gandhi, CIO.com, June 2026). The governance those systems have was built for software that stores; it does not follow the decision to where the software now makes it. In a human-serving organization the gap is older and simpler. The system was never designed around the workday, so little in it serves the workday now.
Whose record is it
There is a sharper version of this, and it sorts an organization’s own platforms rather than its systems in general. Walk the portfolio and two groups come apart. The line between them is not compliance. Student discipline is collected federally, by a mandatory survey of all public school districts, generally collected every two years, that covers discipline alongside enrollment and school climate (Civil Rights Data Collection, U.S. Department of Education). Where a state requires classroom observations, that is an obligation too. Both groups carry one.
One group is kept current, even where every entry is manual. These are the systems an obligation can only be discharged inside. A special-education billing claim is filed from within the billing system, against each entry, and nothing outside it files the claim. Enrollment events, a transfer in or a discharge or a withdrawal, are recorded in the district’s own student information system, which school staff reach with credentials that district issues, and the count that matters for funding is the one in there, not the copy the school holds in its own system. Higher education runs the same way, with a clock attached. A school has fifteen calendar days to report a Pell or Direct Loan disbursement into the Department of Education’s Common Origination and Disbursement system, which the school does not own, and on the advance payment method it draws those funds down from the Department rather than from anything it holds itself (Federal Student Aid Handbook 2025-26, volume 4). In each case the money sits on the other side of an entry made in somebody else’s system, whether it is paid against that entry, counted from it, or drawn from the party the entry is owed to. That is what makes the obligation undischargeable from outside. A local file satisfies none of them, however carefully it is kept, so somebody has to log in.
The other group can be fed later, and nothing governs how much later. Attendance is taken on paper or in a sheet and entered at the end of the day, or the next day, or at the end of the week. A behavior incident is written down somewhere and entered in retrospect. An advising note gets written between appointments, or after the term, or not at all. Nothing breaks when any of that slips, so nothing decides when it happens.
The difference is not that one group is entered by hand and the other is not. Both are. A service delivered and a transfer recorded also begin as somebody’s local note, before anyone logs in to file them. What changes is how long the note is allowed to sit there. Where money is waiting on the entry, the timing is not left to local habit, because somebody is waiting to be paid. Where nothing is waiting on it, the timing is whatever the week allows.
So in both cases what the platform receives is a record that was made somewhere else. The sheet is the working copy and the platform is where it eventually lands, which is the pattern this essay is named for, showing up between platforms rather than between one owner and her system.
So the test is whether the obligation can be discharged from outside the platform or only from inside it, whatever it collects and however often. That test has an uncomfortable consequence, because the systems that only work from inside are usually not the organization’s. They belong to the state, the district or the payer.
Which turns the phrase over. These organizations are not keeping systems for the record. They are keeping them for somebody else’s record. In one network I worked in, the operations lead logged into the district’s system to record a transfer or to track a withdrawal, and then entered the same event by hand into the network’s own student information system. The authoritative version lived outside. What the organization held was a copy, made by a person, downstream of a system it did not control. And the credentials for the system that mattered sat with two or three people, which is its own exposure the first time one of them leaves. The credential boundary is an analytic boundary too. I never logged into either district system myself. What reached me was a monthly spreadsheet, exported by the team that held the credentials, and the dashboards built on it could never be fresher than that export. The people who could see the authoritative record could not analyze it. The person who could analyze it could not see the record. That is why the reporting layer in these organizations goes quiet, and it is not neglect.
Systems for the record, spreadsheets for themselves
What the people do in response has been documented for years. Voida and colleagues called these homebrew databases (CHI 2011), and Bopp and colleagues showed how funder data demands disempower nonprofits (CHI 2017). It is also the mechanism this essay turns on.
They keep their own spreadsheets. Systems for the record, spreadsheets for themselves. Not out of laziness, and not because nobody trained them. The enrollment director keeps a sheet because the system’s applicant count does not match what she knows from the call center. The program manager keeps a sheet because the code she needs was added to the system after her staff had been trained on the old one, and half of them still log the old one. The finance lead keeps a sheet because Intacct was never connected to anything else and the numbers in the warehouse are a copy of a copy. Each owner trusts the sheet they built, because they can see every row and they know what each column means. They do not trust the system, because it was built for someone else’s report and it changes under them.
What that arrangement costs is worth stating, because everyone inside it already knows and nobody writes it down. The same record gets made twice. Once where the work happens, in a form the person can act on, and once where the obligation is discharged, in a form somebody outside requires. The organization pays for both, and only the second one is anybody’s job.
Higher education has a name for the tool version of this. Joel Larson, who directs IT support at Kalamazoo Valley Community College, describes shadow IT as a timing problem rather than a discipline one: it is usually not done for malicious reasons, it is “trying to meet a need within a certain time frame,” and the sanctioned route has to be the one people actually want to use. That makes the unsanctioned tool a reading on the sanctioned one rather than a compliance failure. He also names the risk that follows: someone installs a tool, leaves, and a process now depends on something nobody can support (Parsi, EdTech: Focus on Higher Education, September 2026). The spreadsheet is that same reading taken on the record instead of on the tool, and the difference matters. A tool someone adopted can be replaced. A record someone keeps privately is the organization’s own account of what happened, held where the organization cannot see it.
Once that happens, four things follow. I have watched some version of all four across the sectors I have worked in.
Compliance reporting becomes its own workflow, fed from the local spreadsheets and their owners, and only partly from the systems, because the owners are the ones who have to sign the submission and they will only sign what they trust.
Dashboards multiply. There is one in the CRM, one in the student information system, and one in the BI tool, each built by a different team from a different source, and the local spreadsheets still prevail because that is where the owners look. Sometimes there is more than one BI tool. In one network finance worked in Looker and the school leaders in Tableau, each with its own version of the number. The numbers don’t agree because the words don’t is about why the versions disagree; this is about why there are so many versions in the first place.
Finance and HR stay walled off. In the name of security, the accounting system and the talent system are not integrated with the rest and not loaded into the warehouse. Some of that caution is right. Much of it is a narrative that nobody has been asked to make specific: which fields, to whom, under what contract. So the two systems that hold what the organization spends and who it employs sit outside every analysis of what it does.
And every change loses something. When policy changes (the state issues new chronic-absenteeism codes, say), three things have to happen. The codes get configured in the system. Staff get told where the new field is and who logs it. And the old records get mapped to the new ones, or the trend line breaks. Under the turnover schools and nonprofits run at, the people who were trained on the last change are gone before the next one. At year-end rollover, the system archives what it was told to archive, and what nobody thought to preserve is what the longitudinal question needed three years later.
That is the box. It is not that the organization has no data. It has too many versions of it, and the people trust the version they can see every row of. The system holds another one, and it was set up to produce a report someone outside requires rather than to hold what the work knows.
What the standard advice assumes away
Read from the operator’s chair, the box produces a fixed set of problems, and the advice on offer usually only works if you leave one of them out. Entry is manual and late, because the system captures what the funder counts as a form filled in after the encounter. Training never ends, because turnover takes the skill with it and each policy change resets it; and the appetite for it is finite, because employees can absorb one or two major changes a year while leaders expect three or four over the next two years (Grossman, MIT Sloan Management Review, May 2026, reporting a Grossman Group survey with The Harris Poll). Integration is partial, so the portal, the student information system and the CRM each hold part of a family’s record and someone carries the rest over by hand. Identity lives in unwritten rules. Exports are shaped for a report template rather than a question, with columns that went dead in 2023 and what the program knows about a person sitting in free text. And the outside context that would give the organization’s numbers their meaning sits elsewhere: the region’s enrollment trend, the county’s suicide rate, what happened to last year’s graduates. It lives in the National Student Clearinghouse, a state education department’s reporting portal, CDC WONDER, a regional health information exchange, the National Survey on Drug Use and Health. Few of those can be connected to by one person at a school or a clinic.
The advice comes in two forms, and both assume capacity the box does not have.
The first is to replace or properly integrate the systems. Correct, and not available. The reporting obligation usually constrains which system can be used and how it must be configured, even where no funder named the vendor. Healthcare has larger budgets than anywhere else I have worked. There, a Carta Healthcare survey found EHR integration difficulty the leading barrier to AI adoption, cited by 44 percent of respondents, well ahead of clinician trust and regulatory concerns at 26 percent each (Siwicki, Healthcare IT News, August 2026). If integration is still the first thing in the way at health systems with real budgets, “integrate properly first” is not a credible prerequisite for a community clinic or a charter network.
The second is to clean the data before adopting AI, because AI amplifies a weak foundation rather than repairing it (I-M Technology, July 2026). NYU Langone’s chief digital and information officer puts it as a principle: if you want high-quality data in the intelligence layer, you fix it at the transactional systems first (Mherabi, via Databricks, May 2026). I agree with the description of what goes wrong. What the advice assumes is that someone is funded to clean. Inside the box, “clean first” means never, because cleaning is already the work nobody has hours for. And it assumes the cleaned system will be trusted once it is clean, which the spreadsheet owners have already decided it will not be.
So the question I want to ask is narrower than whether the organization should adopt AI. It is whether AI changes the cost of each constraint in place, without replacing the system, without hiring a team, and without asking the owners to give up the sheet they trust. My answer, from having done the work both ways, is that one mechanism moves a good many of them, and that one thing does not move at all.
Keep the spreadsheet. Carry it in.
The move I would make first is the one that respects where the trust went.
Do not ask the enrollment director to abandon her sheet. Let it stay the working record, because it is the thing she trusts and the thing she maintains. But be exact about what that trust is. The sheet is the surface she works on. It is not, by itself, the truth. It can carry the same faults as the system: a formula copied one row short, a code that stopped meaning what it meant, an override nobody remembers making. What the sheet has that the system lacks is an owner who can see every row. That is worth keeping, and it is not the same as being right.
So the move is a round trip, and both halves matter. A model reads her columns, maps them to the system’s fields and codes through a crosswalk she has confirmed, flags the rows that do not map, and drafts the system entry. She reviews the flagged rows and confirms. The record gets written in the system’s vocabulary, from the source she trusts, on the day. It is written once, from the sheet, instead of being made a second time from the same facts. Then the model carries the other direction: the system’s export comes back to her in the shape of her sheet, with the rows where the record and her working version disagree marked. She resolves them, or the disagreement is logged with a reason. That second half is the point. For the first time the gap between what the worker trusts and what the institution holds is something you can see, count and assign, instead of something you find out about at the board meeting.
Veronika Durgin, writing from the warehouse side, reached the same place from the opposite direction. A warehouse that was good enough for her team turned out not to be good enough for a model, because people know how to deal with imperfections and a model does not; the decisions about which of several legitimate sources of truth applied had lived in people’s memories, and “there isn’t always a correct answer sitting somewhere waiting for AI to find it” (Durgin, Think Solve Repeat, September 2026). Her conclusion is that a model should sometimes ask rather than guess. The flagged rows are that. The model does not resolve the disagreement between the sheet and the record. It surfaces it to the one person who can.
Compliance rejoins the rest here. If the sheets the owners sign from are the sheets the model carries into the system, and the disagreements have been resolved or logged, the compliance report and the system report draw from one source. The owner still signs. What she signs is now also what the system holds.
Why a model, and not another connector
A careful reader will ask why this needs AI at all. Field mappings, crosswalks, record matching and reconciliation have existed for decades. Scripts and integration tools do all of it. That reader is right, and the answer says what the model is for.
Deterministic tools work once the rule exists. What has been expensive in these organizations is getting from the local meaning of a column to a rule explicit enough to automate, for fifty sheets, each maintained by a different person, each changing when a code or a person changes. Writing that rule down has always been an afternoon per sheet, and there was never an afternoon. A model reads the sheet and the system side by side and proposes the rule: this column is that field, this value is that code, these rows do not fit. It will be wrong in places. It is still a first draft that nobody had before, and it drafts the script that runs the rule as well as the rule. What has not changed is the confirming, which is the part that decides whether any of it can be trusted.
So the architecture has three parts, and the model is only one of them. The model proposes the translation. A person who knows the sheet confirms it, and adds the exception the model could not know. Then ordinary deterministic code runs the confirmed translation every cycle, the same way every time, and raises a flag when something no longer fits.
Two of those three are not new here. I named them in When GenAI redesigned my dashboard as a discipline for dashboards: AI proposes, human curates. What this essay adds is the third part and a different object. A dashboard can be curated once and left. A record is written every cycle, so the confirmed translation has to become something a machine executes the same way each time.
That division is also a position on how much the model is allowed to do on its own, and it is a specific one. In Actions, not answers I argued that the checkpoint which used to come free with every answer disappears the moment a model acts rather than replies, and has to be designed back in deliberately. The crosswalk is that checkpoint, built at the seam. The model never writes to the record unsupervised. What runs unsupervised is deterministic code executing a rule a person already confirmed.
The usual way to get more out of an agent is to move it up the autonomy range and build safeguards around the new position. In this seat the better move is the other one: hold the model at propose-and-wait, and push the confirmed rule down into code that runs the same way every cycle. That buys the cadence without the exposure, and it is available because the expensive part here was never the execution. It was the meaning.
That is a claim about who carries the work rather than who watches it, the load-carrier distinction I used in Auditing an AI-native practice to measure my own. Human in the loop and AI in the loop are its two ends, and one question separates them: if the person stopped, would the record still get written? Where the answer is yes, the AI carries the load and the person checks it. Here the answer has to be no, because meaning cannot be overseen from outside.
Where the model sits and what it is grounded against is the placement question Grounding the AI layer asks of the whole stack; here the placement is the seam and the crosswalk is the grounding. Two conditions ride with it, and they are not optional in a school or a clinic. The model works inside the organization’s own approved environment, with the minimum access the task needs, and where the record is sensitive it proposes the write and a person commits it. And the crosswalk is versioned: confirmed, dated, owned, and checked again whenever either side changes. “Confirmed once” is not a state these organizations get to stay in, because codes change, policies change and people change.
It also has to be a governed definition rather than a note, because the failure it prevents is a quiet one. Dmitry Ustimov built a deliberately messy test warehouse and found that bad SQL was the cheap failure. The expensive one was wrong selection: the agent picks a column whose name matches the question and whose definition does not, writes valid SQL, and the chart renders with nothing raised (Ustimov, Decision Spine, August 2026). The person at the desk has been making that same selection by hand for years. A written definition can be tested; a habit cannot.
Untended, it stops being testable. Anthropic’s own data team watched offline accuracy behind an analytics agent drift from about 95 percent at launch to about 65 percent over a month once nobody maintained the written sources of truth (Chang et al., Anthropic, June 2026). The maintenance does not disappear. It moves from reconstructing what a column meant every time someone asks, to keeping one explicit seam current. That is a much smaller job, and it has to be someone’s.
Move record-making inside
There is a picture I keep drawing for this, and it is worth putting on the page.
In most of the organizations I have worked in, the systems box sits outside the boxes where the work happens. Each of those boxes fills with its own spreadsheets, because that is where the trust went. Headcount grows and the sheets grow with it. Coordination gets harder, because there are more versions and more people keeping them. Eventually the borders give: the program cannot say what it did last year, the people cannot find what the previous person knew, the process is whatever the current spreadsheet says it is.
The round trip puts record-making inside the work. The working sheet stays; it becomes the surface through which the record is written, and the crosswalk is the seam. Once the seam exists, the boxes have less reason to inflate. The version they trust and the version the system holds are reconciled on a schedule. The places where they legitimately differ (a local note, a timing gap, an override with a reason) are written down rather than hidden. Side sheets will still appear. The difference is that their relationship to the record is now explicit. Over time the borders get stronger, because what each box knows survives the people in it.
I want to be careful about one word. The instinct is to say AI blurs the boundary between the trusted sheet and the official record. I think the opposite happens when the move works. The boundary was blurry before; nobody could say where the sheet ended and the system began, which is why nobody trusted the system. The crosswalk draws the line. It is written, it has an owner, it has a version, and it can be checked. What AI changes is that the line gets drawn cheaply and crossed on purpose.
Same architecture, different seams
Once you see the three parts (a model proposes meaning, a person confirms it, deterministic code preserves it), the other constraints in the box turn out to be the same architecture applied at a different seam. Not every seam is a round trip between a trusted sheet and a record; the outside-data case below is closer to access, translation and provenance. The division of labor is the same. I take two here, and the companion essay, The delta nobody budgeted., takes four more. The first of the two shows most clearly what is being converted.
Identity. Matching one person across the portal, the student information system and the CRM has been done by rules nobody wrote. Same birth date, last name within two characters, except for the students enrolled during the few weeks when the front desk was typing the wrong birth year. A model can propose the matches and, more usefully, propose the rules it is using in plain language. The person who has done the match by hand for three years reads them, adds the exception, and the rules become a versioned file the next person inherits. Some knowledge really is tacit. James Scott’s point that every production process depends on informal knowledge that resists full codification stands (Scott, Seeing like a state, Yale University Press, 1998, ch. 9). Thea Snow is right that a home visit reveals things a database does not; her social worker’s test is whether there is food in the fridge and whether the carpet is sticky (Snow, Notes from a Shoulder Season, August 2026). But there is a difference between knowledge that resists being written down and knowledge that nobody has written down, and organizations routinely treat the second as though it were the first. The rule that “an applicant is who SchoolMint says they are unless HubSpot has them flagged,” which I described in The contracts between systems, was never uncodifiable. It was unrecorded, because recording it cost an afternoon nobody had. So is the front-desk exception. In the organizations I have worked in, what got called institutional knowledge was often not impossible to write down; it was nobody’s funded job to write it down. What AI lowers is the cost of attempting to make the rule explicit. Where codification stops is still something a person finds out, by use and by exception. Identity is where the attempt usually succeeds, because the rules are comparisons between fields plus a list of exceptions. It is also where to start, because the counts and the reports downstream depend on knowing which records are the same person.
The outside. An enrollment decline can mean the school is losing families, or it can mean the region has fewer children in it, and the context that settles which sits in the state education department’s reporting and in the National Student Clearinghouse. Pulling it and keeping it current was a job, and the job was nobody’s. One person can now do it, because I did: the PDDS panels pull public sources through a dbt pipeline with a model drafting and deterministic gates checking every claim (Extending the gates). Two limits stay. Where a source keeps its download behind a login, a person still has to go and get it, and provisional data gets revised, so a context number needs its vintage on it.
That is enough cases here. The four the companion takes sit one piece over: what happens when the world changes and the configuration does not. A state policy that reissues the codes. A vendor release that lands two quarters late. A year-end rollover that drops the field a trend needed. A model upgrade that arrives with no notes at all. Same division of labor, applied to change rather than to distance. That is the subject of the companion to this essay, The delta nobody budgeted. The absorbed data role is about who has been carrying all of them on top of a real job.
What does not move
Every gain above carries the same condition. The crosswalk needs a confirmer and a version. The identity rules need someone who knows the exception. The context needs a vintage, and the field list for finance needs someone with the authority to sign it. The same holds for the artifacts the companion essay produces, the policy map and the preservation list, because the file this essay ends by asking for is one artifact spanning both.
The cost of producing each of those artifacts has dropped. The cost of owning them has not. Two surveys of different populations show the shape of the risk rather than its size. dbt Labs surveyed 363 data practitioners and leaders on what they prioritize and found 72 percent on AI-assisted coding against 24 percent on AI-assisted pipeline management (dbt Labs, State of Analytics Engineering 2026). Among 346 nonprofits surveyed in late 2025, 92 percent use AI, 81 percent use it on an ad hoc basis, and 7 percent report major improvement in their ability to achieve their mission (Virtuous and Fundraising.AI, 2026 Nonprofit AI Adoption Report). Neither survey measures what I am claiming, and read together they are consistent with it. My reading is one owner at a desk, using a model to get through Tuesday faster, and writing nothing down. The constraints ease for that person. The organization keeps the same box, with one more version of the number in it.
Matt Hennessey, chief data and analytics officer for NHS Greater Manchester, states the condition directly in an argument about where decision rights should sit. Local control without local capability, he writes, “is simply the transfer of responsibility without the means to discharge it,” and the unit of currency should be capability rather than product (Hennessey, LinkedIn, August 2026). His subject is a health system rather than a spreadsheet on a desk, but the condition is the same one. Keeping the sheet with the owner is right; calling that the answer is what moves the responsibility without moving the means.
Four jobs, one loop makes the general form of this argument at the level of a measurement function: infrastructure and AI make production through the middle of the loop cheap and supply no owner for the reasoning that keeps it whole. This is the same argument one level down, at the desk where the sheet lives. AI makes crossing the boundary between the worker’s record and the institution’s cheap. It does not decide what is allowed to cross, what becomes authoritative once it has, or who owns the mapping.
The finance and HR wall is that in its hardest form, and the pitch will imply a model dissolves it. A model does not open Intacct. The security narrative is a governance position, and the only thing that answers a governance position is a specific one: these fields, to this warehouse, read by these roles, under this contract, with this audit trail. That is the governance contract The contracts between systems describes, and it is written by people with authority. What a model can do is draft the specific proposal, from the two schemas and the questions the organization wants answered, so the conversation is about a named list of fields rather than about “security” in general. In my experience the security argument has survived because nobody has been asked to make it specific. Drafting the specific list is now a model’s first pass. Deciding what goes on it is not.
Decision load vs decision capacity sets out the argument that organizations fail when decision load exceeds decision capacity, and that capacity is an architecture you build rather than a headcount you hire. So: does AI add capacity inside the box? It does, and the seam is where. But capacity only counts if it lands in the architecture. A model that drafts a crosswalk for one owner who keeps it on her desktop has added capacity to her Tuesday. A crosswalk that is confirmed, versioned, filed where the next person finds it, and run by the system entry every cycle has added capacity to the organization, because the next owner inherits it and the compliance report draws from it.
In Plumbing got upgraded. The water didn’t. I said the pipe now carries speed cheaply and that resolution and context were the two knobs left at their defaults. The seam is what turning those knobs looks like from the operator’s chair: the record at the resolution the owner already keeps, and the context the outside data was always holding. The pipe can carry it now. The organization still has to decide that it will.
What to ask for
For whoever runs a program, a school, a clinic, an agency or a campus unit with no data team of its own, and for whoever holds the absorbed role inside it, the ask comes in an order.
Start by finding out which of your platforms is a point of discharge. Take the platform list, and write down five things about each one.
- 01The obligation. What is owed out of this platform, and to whom: a claim, a count, a report, a filing, or nothing at all.
- 02Inside or outside. Whether that obligation can be discharged from a record made somewhere else, or only from an entry made in this platform.
- 03The credentials. Who can log in and file, named as people rather than as a department.
- 04Upstream or downstream. Whether your copy is the one the event was first recorded in, or a copy of a version held somewhere else.
- 05The hops. How many hands the record passes through between that version and whoever reports on it.
Then read the answers. A platform carrying no obligation that can only be discharged inside it is discretionary, whatever the procurement memo said, and should be resourced on that basis or retired. Where your copy is downstream, say so on the dashboard. A number carried across by hand from somebody else’s system has a vintage in the same way a public data release does, and nobody reading it can tell unless you write it down.
The audit is not an argument for owning fewer platforms. Discretionary does not mean worthless, and the working sheets this essay spends its length defending are discretionary by this test. What the audit tells you is which platforms stay current on their own and which do not, and the two groups need different things.
A platform on the discharge side keeps itself current, because a payment or a filing is waiting on the entry. It is still making the record twice, once in the sheet where the work happens and once in the platform where the obligation is discharged, and the round trip, which writes the record once from the sheet, is what removes the second making. On the other side nothing is waiting, so the platform stays current only if somebody is given the step, the time and the reason to make the entry. That is a staffing and process question rather than a software one, and the two places to answer it are procurement and implementation. The round trip belongs here too, because part of why the entry does not get made is that making it is a second job nobody was given. The alternative is to answer all of this a year later, when the platform is empty and the explanations still available are that people need more training, or that another system would fill the gap.
Point AI at the seam between the trusted spreadsheet and the system of record, before pointing it at the analytics. Keep the working sheets. Let the model propose the translation, let the owner confirm it, and let ordinary code run it. A dashboard built on top of a system the owners route around inherits everything that did not get entered.
Then change what counts as the output of that work. The number for the board is not the deliverable. The file is. I am using “file” loosely, and on purpose: one maintained record of what the organization’s data means, kept where the next person can find it, readable by a person and usable by a machine. Some of it is prose, such as what a status code meant and who decided. Some of it should be a table a program can run, such as the crosswalk and the identity rules. It carries the crosswalk from each owner’s sheet to the system’s fields, with its version. It carries the identity rules with their exceptions, and what each field and code means in the words of someone who checked. It carries the definition and vintage behind each reported number. And because it is one artifact across both essays, it is also where the old-to-new map for each policy change and the preservation list from each rollover belong. A model drafts every part. A person confirms each part and signs. The compliance report cites it, and when a code changes, the file changes first.
The ask is small, but it can be adopted wrongly. One wrong adoption is the file as a documentation project: write down everything, make the systems “AI-ready.” Durgin is right that this is impossible and misses the point, and that the place to start is the problem you are trying to solve. The file is scoped the same way. It covers the numbers the organization reports and the decisions it makes on them, and nothing else until a new number or a new decision needs it. The other wrong adoption is a file the model wrote and nobody read, saved beside the fifty sheets as the fifty-first. The test is whether a stranger, handed the file and the exports, could reproduce Thursday’s number. If they cannot, the work has been made faster and not recorded.
For a funder or a board, the ask is smaller and it is not another report. Do not ask for the file; that would make it one more thing built for someone outside, which is where this essay started. Ask whether it exists, and whether the number in front of you can be traced back to it. An organization that can answer yes has turned its owners’ private trust into something the organization holds. An organization that cannot has a better-looking report, three BI tools, and the same sheets.
School ops turns over, and network operations trains whoever comes next. The worksheet survives all of it, because a file does. What does not survive is the part that made the worksheet worth more than the system: knowing which rows had been amended, on whose understanding, and why. The columns stay and the reasons leave with the person who entered them.
So the next time the report comes round, somebody reconciles the two numbers again, from the beginning, by hand. That is what I was doing that day, and somebody had done it the year before, and nothing either of us worked out was written down anywhere the next person would look.
Written September 2026 for the Analytic Bytes Library. No employer, client, authorizer or funder is named; every seat is described by role and in de-identified form, per standing practice. The opening reconciliation and the inside-or-outside discriminator are from the author’s own record. External sources were verified against their live pages in September 2026, and the verification log, text snapshots and review rounds are held in the piece’s source pack. One claim was cut rather than carried: how many states require classroom observations was not checkable at reasonable cost, and the argument does not need it.
Questions, pushback, or a problem that looks like this one? Write to chai@analyticbytes.systems.