DEV Community: David Aronchick

The Pope and the Dynamo

David Aronchick — Sat, 30 May 2026 18:17:53 +0000

On Monday, Pope Leo XIV released a 42,300-word document about artificial intelligence. The English text runs ninety pages, named it Magnifica Humanitas. He picked the date of signature for May 15, the 135th anniversary of Rerum Novarum, which is the 1891 encyclical on labor, capital, and the industrial revolution.

I find it INCREDIBLY interesting that AI has now reached a point where religious figures feel the need to weigh in. The Pope is worried about AI in warfare, and he is, and the final chapter is direct enough about it that the just-war tradition gets explicitly retired. But I read the document (so you don't have to? but you should?) and that is a small fraction of what I took away.

Specifically, the 1891 problem, for lack of a better term, is back, the Catholic Church has had a hundred and thirty-five years to think about that problem, and the answer it landed on then is the same shape as the answer it would land on now.

What 1891 was actually about

Rerum Novarum was published into a world where electrical power and steam-driven manufacturing had centralized the means of production in a way that was new in human history. A worker who used to own his tools and the seasonal value of his labor was now showing up to a factory floor where someone else owned the boilers, the looms, the dynamo, and the building that contained all three. The 1891 question was not "is technology good" since the concept of technology barely existed - it was all just "stuff" that let you "work faster." The 1891 question was who gets to own the dynamo, and what the rest of society owes to the people whose labor is now mediated by an asset they will never personally afford.

Leo XIII's answer was specific and, for the time, contrarian. He defended private property against the socialists, defended workers' associations against the laissez-faire crowd, and insisted the state had a role to play that neither side wanted to admit. He also insisted that the family and the parish and the local trade group all had functions that should not be absorbed upward into the corporation or downward into the atomized individual. That tradition is called subsidiarity. The idea is that decisions get made at the smallest competent unit, and authority only moves upward when the smaller unit cannot do the job.

Not to turn everything into computer science, but subsidiarity is, accidentally, a load-balancing principle, that is core to how a working distributed system gets built. The decision should happen where the data is, where the context is, and where the people affected by the decision actually live. Authority that gets bumped up a layer when it should have stayed local tends to ossify into something nobody asked for, and once it is up there, you cannot get it back down without breaking something.

I want to be careful here, because it is easy to make a Pope into a mascot for whatever position you already held. The encyclical is not a Distributed Thoughts blog post; it is a moral and theological document with an institutional purpose, written for 1.3 billion Catholics, and the parts of it that talk about transhumanism and embryonic dignity are not the parts I am qualified to summarize.

The part I am qualified to summarize is the part that maps to the architecture conversation, and the encyclical itself invites that mapping. Pope Leo XIV does not write about "agents." He does write about subsidiarity in the algorithmic age. He does not use the words "data sovereignty." He does spend about ten thousand words arguing that the asymmetry between the people who own AI infrastructure and the people whose labor is increasingly mediated by that infrastructure produces the same structural problem Leo XIII identified in 1891. He concludes that it does, and goes on for a while about why.

Who showed up to the launch

The presentation on May 25 was attended by, among other people, Chris Olah, who runs interpretability research at Anthropic, is one of the company's co-founders, and gave remarks at the press conference. The remarks said, more or less, that the labs operate inside incentives and constraints that can conflict with doing the right thing, and that people outside those incentives need to pay close attention and be willing to be honest critics. He thanked the Pope for being one of those critics. He used the word "unsettling" about what his own team is finding inside frontier models.

Sit with that for a second. Anthropic flew its head of interpretability to Rome to stand next to the Pope and say "we need outside oversight because we cannot reliably oversee ourselves." Whatever else you think about that, it is the most theologically literate move any of the labs has made in three years. The other labs noticed. The Washington Post coverage framed Anthropic's appearance as a deliberate alignment away from the White House and toward the Vatican, which, regardless of intent, is now the cleanest description of where the moral high ground of this debate actually lives.

The 1891 prescription, in 2026

The labs are very willing to talk about safety. They are very unwilling to talk about who owns the dynamo. The Pope just wrote ninety pages saying the second question is the question, and that the first question, on its own, gets you nothing useful. You can build the safest possible model and still hand it to eleven counterparties under a Glasswing-class contract the rest of the market cannot sign, and you will not have addressed any of the questions a serious moral framework would have asked you to address. You will have addressed about half of one of them.

I do not agree with everything in Magnifica Humanitas. I do not need to. The point is that the institutional response to a wave of centralized infrastructure is forming, the framework that is going to do the most coherent intellectual work over the next decade was just published by a 70-year-old Augustinian, and the people responsible for the centralization have, with one notable exception, not read it.

They should. The diagnosis is good. The diagnosis was already good in 1891. The prescription is the same as it was then, which is that authority not held locally tends to ossify into something nobody asked for and nobody can leave. The labs have built infrastructure of exactly that shape. The grid bills are going up. The data center moratoriums are spreading. The people whose work is increasingly mediated by the model cannot vote on it, cannot leave it, and increasingly cannot afford the electricity it draws.

Push the decisions down. Push the compute down. Keep the dynamo close enough that the parish can see it.

That is what 1891 actually figured out. The Pope is the one who remembered.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

NOTE: I'm currently writing a book based on what I have seen about the real-world challenges of data preparation for machine learning, focusing on operational, compliance, and cost. I'd love to hear your thoughts!

Originally published at The Pope and the Dynamo.

The Company Store

David Aronchick — Wed, 27 May 2026 18:44:02 +0000

On May 1, Google Cloud doubled the egress rates on three products: CDN Interconnect, Direct Peering, and Carrier Peering. The reason given was "significant investments in global infrastructure," and the rate increase applies automatically with no opt-out. If you serve objects from a Google Cloud Storage bucket through Cloudflare or Akamai or Fastly, your cost of getting your own bytes back out of Google's network just doubled in North America, and Google did not need you to agree to it.

I have been trying to find a contemporary parallel for what this is for about a week, and I keep landing in the same place. The parallel is coal scrip.

A few weeks ago, I wrote about the Pullman strike (and make some significant errors, pointed out by Tim Banks, please read up on it!) If you read American labor history at all you have at some point run into the company town. Pullman, Illinois is the famous one. Pullman is famous for the strike, not for the scrip, and it turns out the National Park Service will tell you politely that George Pullman did not actually pay in scrip. The real scrip towns were in the coal country of Kentucky, West Virginia, and Virginia, and roughly seventy-five percent of all the scrip ever issued in the United States was issued by coal operators in those three states. The mechanism was the same everywhere, wher a would miner get paid in chits that were only good at the company store. The company store sold flour and bacon and lamp oil at whatever price the company felt like setting that month. But if you tried to spend the chits anywhere else, you got fifty cents on the dollar at best, sometimes nothing. If you tried to leave town, you had to pay off whatever debt you had run up at the store first, and the store kept the books. The wages went up every year, but the cost of leaving went up faster.

The point of scrip was never the price of bacon. The point of scrip was the asymmetric power to set the price, and the impossibility of carrying the value of your labor across the town line without taking a haircut so deep that most people did not bother to try.

That is what cloud egress is.

The bytes themselves cost the cloud provider almost nothing to ship out. The marginal cost of pushing a gigabyte from a Google data center in Iowa to a customer's office in Sydney, in 2026, on amortized fibre that has been in the ground for fifteen years, is ALMOST to cheap to meter. The list price is, depending on the destination and the discount, somewhere between eight and twelve cents per gigabyte. The markup is not a revenue source; it is a fee for leaving which is not set by what it costs the provider, but what the customer can be made to swallow before the migration to another provider becomes worth the engineering pain. And as the pain bar moves up over time, the fee moves up to track it.

Google's May 1 increase is, on its face, a routine pricing action by a single cloud, on a single product line, with a stated rationale. The customer's CDN, Cloudflare or Akamai or Fastly, is the one billing the customer downstream, so the price increase shows up on a different invoice from the one the customer associates with Google. The customer feels the bill climb at the CDN, calls the CDN, gets told the increase came from Google's peering rates, calls Google, and gets told that the rates are public on the website. And, while both statements are true, the combined effect is that nobody is on the hook for the increase in any conversation the customer is allowed to have. The miner walks into the store, the price of flour has gone up, and the man behind the counter shrugs.

Coal scrip ended for a few reasons that are worth keeping in mind.

The mechanical reason was that paying workers in anything other than legal tender became illegal in most coal states between roughly 1909 and 1940. Federal labor law caught up with the scheme. The Norris–LaGuardia Act and later the Fair Labor Standards Act made the scrip economics impossible to enforce, and the scrip stores collapsed because the wages they depended on stopped being denominated in store credit. The legal substrate underneath the lock-in fell out.

The economic reason was that workers stopped accepting scrip jobs once enough mines were paying in dollars. The scrip mines tried to compensate by raising nominal wages, but a real-dollar miner with a real-dollar wage and a real grocery store across the road did not need a raise to be poached. The wage premium that scrip mines had to pay to keep workers eventually exceeded the rent the company store could capture, and the scheme stopped being profitable.

The cultural reason was that the population of the United States stopped being willing to accept the fiction that this was just how mining was done. Scrip looked normal in 1900 and crazy in 1940 because the country changed its mind about what counted as a wage.

I do not think the cloud version goes the same way for any of those three reasons in the same order. The legal substrate is a long way from arriving, because regulators do not have a clean precedent for compelled price floors on a service that the customer technically opted into. The competitive substrate is closer, because hyperscaler-to-hyperscaler migration is real, but the per-customer cost of executing it is still measured in years of engineering time, and the migration tools are written by the same vendors that benefit from migrations being hard. The cultural substrate is, I think, the one to watch. The cloud customer in 2026 is starting to talk about egress and lock-in the way a 1925 miner started to talk about the company store. Which is to say, with the particular kind of dawning irritation that comes from realizing the deal you signed last year is not the deal you are now in.

The European Commission is about to drop its Tech Sovereignty Package on May 27, with a Cloud and AI Development Act inside it that is, in essence, the legal substrate question asked back to the hyperscalers. Whether that particular bill survives the lobbying gauntlet between now and the autumn of 2027 I have no idea. The fact that it was written at all is a leading indicator. Once a sovereign starts drafting a statute that says "your customer should not have to pay you a tax to leave," the company-store window is closing whether or not that particular statute passes.

The architectural answer is not "stop using cloud," which is a strong and (usually) dumb position to take. The architectural answer is to refuse to put any system in a place where the cost of leaving compounds against you faster than the value of staying. START thinking about how to federate the workload across providers before you need to, or against your own physical infrastructure, or both. Then you can put the data where it is going to be read most often, and design the system so that the next migration is a routing-table change instead of a six-month engineering project. The boring word for this is portability. The slightly less boring word is sovereignty. The accurate word, if you have been paying attention to the coal towns, is carrying your own wages out of town.

The 1940 version of cloud egress is some combination of all three of the reasons coal scrip collapsed. We can argue about which one matters most. We cannot, I think, still argue with a straight face about whether the parallel applies. Google just doubled the price of leaving. Nobody got to vote.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.

Originally published at The Company Store.

The Merging Was Always the Point

David Aronchick — Fri, 22 May 2026 00:20:21 +0000

Yesterday, an internal model at OpenAI disproved the Erdős unit-distance conjecture. The conjecture is from 1946. It is, depending on which discrete geometer you ask, either the best-known or the most-tried open problem in combinatorial geometry. Paul Erdős attached a $500 prize to it. The disproof is, according to the nine mathematicians who examined it line by line, correct.

Let me say what the problem actually is, because It took me forever to understand it (did i mention I am not a mathematician??)

Put n points in a plane, anywhere you want. Count the pairs of points that are exactly distance 1 from each other. Call that count the "unit distances." How big can the count get as n grows? Erdős showed in 1946 that you can get the count to grow a tiny bit faster than n itself. He conjectured that you cannot do much better than that, formally that the count is bounded by n raised to (1 + o(1)), where the o(1) shrinks toward zero as n grows. Eighty years of human effort have, broadly, been on the side of proving that ceiling. The model showed there is no such ceiling. You can construct point sets that beat the bound by a fixed exponent forever.

The way it did this is, if you squint at it, the most ordinary thing mathematics has ever done.

The original Erdős construction was a square grid of points where the coordinates were ordinary integers, and the unit distances came from the algebraic structure of the Gaussian integers, the ring Z[i], the same object you saw the first time you took a course on complex numbers. The natural generalization is to swap the Gaussian integers for some other algebraic object of the same shape and see whether you get more unit distances No matter what they tried, the bound would stubbornly recover Erdős's original number. Will Sawin's reflection in the companion paper explains why: when you actually compute it out, the natural generalization gives you the same answer as the original construction, so there is no apparent reason to try anything else.

So this is where we get to the novelty - here the model tried something else.

Specifically, it took the construction and varied the wrong thing, and instead of fixing the field and varying which primes you use inside it, it fixed the primes and varied the field, letting the field's degree grow to infinity along a particular tower of fields known to algebraic number theorists since the 1960s. This regime is, according to Jacob Tsimerman, who briefly tried it himself, "very scary." It's hard to hold in your head as the obvious calculations do not give you any signal that it is going to work. Humans who got this far typically wrote it off as a dead end and turned around.

The model did not turn around. It also did not need to be intuitive about whether the conjecture was true. As Arul Shankar observed in his reflection, a "significant majority" of the model's chain-of-thought was spent trying to construct a counterexample, not a proof. Erdős believed his conjecture for forty-six years until he died, and no one else had a reason to disbelieve one of the greatest mathematicians of all time. The model did not believe anything.

Every meaningful breakthrough in modern mathematics has, at its core, been a merging. Andrew Wiles proved Fermat's Last Theorem by realizing it was the same problem as a question about elliptic curves and modular forms, three areas that, before Wiles, were not visibly the same conversation. Guth and Katz almost-solved the distinct distances problem by importing the polynomial method from algebraic geometry into combinatorics. The Langlands program is one giant unfinished exercise in merging seemingly-separate domains into one structure. You can pull on this thread for a long time. The history of mathematics is the history of noticing that things you thought were separate are the same thing seen from different angles.

The OpenAI model did the merging. The model took a discrete geometry problem, recognized it as algebraic number theory wearing a hat, walked over to the algebraic number theory shelf, picked up a tool from 1964 (Golod-Shafarevich), combined it with a tool from 2007 (Ellenberg-Venkatesh), combined those with a tool from 2021 (Hajir-Maire-Ramakrishna), and used the combination to do something none of those tools had previously been used for. This is no different in kind from what humans have been doing in mathematics for four hundred years.

Then we get to the more fundamental question which is... is this what thinking is?

When you have an insight, the experience of insight is the experience of recognizing that something you knew from over there applies to something you are stuck on over here. It is not, despite what the romantic version says, the arrival of a new fact from nowhere. There is no atomic operation called "having an idea." There is pattern-matching across stored experience, and there is the moment when the pattern lights up and you see that two things are the same thing. That moment is what thought is.

If that is true, then "is AI really thinking?" becomes a less interesting question. Thinking is a specific operation that can be performed by anything that can go through that motion. The OpenAI model has access to a much larger stored library than any individual mathematician, runs the pattern-match faster, does not get tired, and crucially does not feel embarrassed when the pattern-match takes it into a domain where it is not formally credentialed. That last one matters more than people give it credit for, in my opinion. Mathematicians have careers. Careers have specialties. Specialties have social costs for stepping outside them. The model has no specialty and no social cost.

This isn't AGI though... not yet.

The model did not pick the problem, nor did the model did not decide its output was worth listening to. Nine mathematicians spent serious unpaid weekend time turning the raw output into a paper that other mathematicians could read. Melanie Matchett Wood makes the sharpest version of this point in her reflection: if the same nine experts had been assembled a month ago to look for a counterexample, she thinks they would have found one. The reason no one assembled them is that no one knew to ask. The model's contribution was not just the proof; it was the act of producing a thing convincing enough that experts would spend a weekend taking it seriously. That convincing-enough threshold is a thing humans have spent centuries building social machinery to enforce.

So the part that is genuinely new is not "AI can think." We have known that since at least DeepMind's AlphaGo move 37, and probably longer. The genuinely new part is that the operation can now be aimed at problems human mathematicians had not given themselves permission to seriously work on, and produce output that crosses the threshold where humans agree to look at it.

The asking is still ours. The deciding-to-look is still ours. The "this is interesting enough that I will spend my Saturday on it" is still ours. Those turn out to be different operations from the merging, and we did not know that before. We do now.

So while the the model disproved a conjecture, the mathematicians disproved a quieter one: that the part of mathematics that requires merging across distant fields is the part that requires a mathematician. We are going to have to find a new place to draw that line. The drawing of the line is also, of course, ours.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

Originally published at The Merging Was Always the Point.

The Frontier Became a Club

David Aronchick — Fri, 15 May 2026 00:18:03 +0000

Last week Anthropic announced Project Glasswing, the deployment program for the new flagship preview model Claude Mythos. The announcement framed Glasswing as a safety initiative. Mythos would not enter general availability. Instead it would be made available to a "small set of partner organizations under elevated trust and safety review," with structured oversight, third-party audits, and a controlled deployment timeline. The press wrote it up as a thoughtful pause. The companies on the list called their solutions architects.

The companies on the list are: Amazon Web Services, Apple, Cisco, CrowdStrike, Google, JPMorgan Chase, the Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, and a single research organization the announcement does not name publicly. Each one receives a $100M usage credit, drawn against future commercial usage at preferential pricing. The credit is structured as a multi-year commercial commitment, not a grant, which means each name on the list also represents a guaranteed minimum revenue line on Anthropic's books and a co-development relationship that lasts the length of the contract.

On paper this is a frontier-safety program. Read sideways, it is a hundred-billion-dollar-class commercial alliance, with eleven counterparties, that has decided who gets to run production workloads on the most capable model of 2026 and who does not.

I want to be careful about the framing here. The safety review work that goes into a Mythos-tier deployment is real, the Responsible Scaling Policy is not a marketing document, and the engineers running the partner reviews are not in bad faith. None of that is the part that matters for the rest of the industry. The part that matters is structural. For the first time since the GPT-3 API opened in 2020, the frontier of large-model capability is no longer available to a developer with a credit card. It is available to eleven counterparties under a contract the rest of the market cannot sign.

What being on the list actually buys you

People who have not worked inside one of these alliances tend to read access asymmetry as a feature flag or a latency edge. It is neither. The access asymmetry is co-development.

When a foundation-model lab signs a strategic partnership with a customer at the Glasswing tier, the work that gets done is not "we have an API endpoint that returns Mythos tokens." It is a multi-quarter, multi-team integration in which a solutions architecture team from the lab sits inside the customer for a year, the customer's eval pipelines and the lab's eval pipelines become shared infrastructure, the production telemetry is in dashboards both organizations can see, and the customer's roadmap feeds back into the next model's training mix. This is the pattern that produced the Google Cloud-Anthropic relationship, the AWS Bedrock integration, and every other "deep integration" headline of the last three years. It is the moat. Once it exists, you are not "using" the model. You are running on a version of the model that nobody outside the alliance can replicate by re-pointing an SDK.

The eleven Glasswing partners are getting that, against Mythos, for the next eighteen months. By the time the next capability tier ships into general availability, they will have shipped production systems with an integration depth the rest of the market cannot match in any reasonable timeline. That is the asymmetry. It is not access. It is co-evolution, on a clock the non-partners cannot stop.

There is a second piece of this that the safety framing politely avoids. Several of the named companies operate in regulated environments where deploying a frontier model into a customer-facing application is, today, a legal grey area. JPMorgan Chase cannot, without a license, expose a Mythos-class model to retail banking customers in New York under the draft NYDFS AI guidance. Under Glasswing it can, because the structured-review program co-signed by Anthropic and a compliance partner becomes the regulatory submission itself. The same logic applies to CrowdStrike in endpoint security telemetry, Palo Alto Networks in network traffic inspection, Apple in anything that touches a device, and Cisco in everything touching a customer's network edge. Glasswing is doing double duty. It is a model-access program and a regulatory-cover program, and the companies on the list will spend the next year writing the case law for what a "trusted frontier deployment" looks like. The companies off the list will be regulated against that case law without having helped write it.

The third piece is talent. The most capable foundation-model engineers in the United States make decisions about where to work, in part, by reading the access announcements. An engineer choosing between two equivalent offers in May 2026, one from a Glasswing partner and one from a non-partner, is making a decision about which side of the frontier-access wall they want to be on for the next two years of their career. The wall is one-directional. Once you have shipped a Mythos-class production system you are valuable inside the club and gradually less valuable outside it. The talent flow over the next eighteen months follows the access asymmetry, and the access asymmetry compounds because the talent followed it.

The argument I am willing to grant

The case Anthropic and its partners are making is not weak, and the strongest version of it deserves a serious hearing.

A model at the Mythos capability tier is the first system in the public record where a sufficiently motivated actor could plausibly extract meaningful uplift on a non-trivial set of dual-use domains. Open release of such a system is, under the current RSP framework, a decision the lab is not prepared to make. A graduated release into operators with established compliance infrastructure, audit relationships, and contractual liability is a way to keep the capability frontier moving in production without exposing the underlying model to misuse the lab cannot yet defend against. Nuclear power did this. The FDA medical device pathway does this. The pattern of "novel high-capability technology released first into a small set of trusted operators, then broadly" has, in domains far more dangerous than chatbot text, produced functioning markets over time. The argument applies. I grant it.

What the argument does not address is the part the analogy quietly skips.

Graduated release in nuclear did not produce eleven private operators with $100M in directed credit and a co-development moat against the rest of the industry. It produced the Nuclear Regulatory Commission, a federal licensing regime, and the principle that a reactor operator is a public counterparty subject to a rule set any qualified applicant could meet. The FDA medical-device path licenses by device class to any applicant who clears the bar, not to a pre-selected eleven. In both cases the trusted-operators pattern was bounded by an open licensing regime. Glasswing is not. It is bounded by an Anthropic-internal partner selection process with no published criteria, no appeal, no statutory floor under who can apply, and no public review of who was rejected. The eleven are not a regulated class. They are a chosen class. The choosing was done by the entity that captures the commercial value of having chosen. That is not a safety regime. It is, structurally, an alliance with a safety review attached to it. The two things can be true at the same time, and both are.

Where the production work moves now

If the capability frontier is fenced off, the production AI work the rest of the industry needs to ship in 2026 has to go somewhere. The somewhere-else determines what enterprise AI looks like for the next two years.

There is a tier-down path. You move to the current open-weights frontier, which today means some mix of Llama 4.5, the Mistral Mythoclast checkpoint, DeepSeek V4, and a handful of specialized open releases from Cohere, AI21, and xAI. None is at the Mythos capability tier. But on the median enterprise task the gap between "Mythos-class" and "strong open-weights" is smaller than the gap between either of those and a 2024 baseline, and the gap is closing on a six-month timescale, not a multi-year one. Most enterprise workloads do not need the frontier. They need a competent generalist the deploying organization actually controls. The open-weights frontier is that, and a meaningful chunk of the industry is going to take this path because it works.

There is also a sideways path, and it is the one this site has been arguing for since I started writing it. You stop building against a single proprietary frontier model accessed through a single API endpoint and you build against a federation of smaller models running close to their data, composed against each other under a routing layer the deploying organization controls. The continuity of that architecture does not depend on any single model lab's willingness to serve you. The ceiling on raw capability is lower per call, but the system-level capability scales with the federation rather than with any one component. It is harder to build, you cannot put a single vendor logo at the bottom of the procurement slide, and it requires the deploying organization to invest in data infrastructure that the centralized-model path lets them defer. It is also the only architecture that is robust to next year's version of the Glasswing decision, because there is no single frontier to be denied access to. The frontier is decomposed into capabilities that live in different places.

These two paths coexist in the short run. Over eighteen months they diverge fast and they do not converge again on a common substrate. By 2028 there will be two enterprise AI stacks. The first looks like Glasswing continued. Thick partner integrations against a small number of labs, with most of the platform value captured by the labs and their named consortium members, regulatory case law written by the partners, talent flowing toward access. The second looks like federated, locality-respecting, open-weights composition with no single counterparty in a position to decide who gets to the frontier because the frontier has been disassembled into things that move closer to the data.

Both stacks will exist in 2028. The interesting question is not which one is technically better. They are optimized for different buyers. The interesting question is which one your organization is on the receiving end of, and the answer to that question is being decided right now in budget meetings that are not framed as architectural decisions but are. If you are one of the eleven, the work is real and you should do it well. If you are not one of the eleven, the work is also real, and the cost of waiting eighteen months to see whether the list grows is eighteen months of integration depth the partners are building against a model you cannot deploy.

The frontier did not become unavailable. It became a club. The interesting question this year is not whether you get in. It is whether you build the alternative while the door past it is still cheap to walk through.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

Originally published at The Frontier Became a Club.

Welcome Back to Pullman

David Aronchick — Tue, 12 May 2026 18:31:49 +0000

In 1880, a man named George Pullman bought a stretch of prairie thirteen miles south of Chicago and built a town on it. Not a town in the sense of a place people chose to live - a town as a piece of industrial infrastructure for a single company. Pullman's Palace Car Company manufactured the luxury sleeping cars that defined American long-distance rail travel, and Pullman had decided that the workforce, the housing, the gas works, the water plant, the library, the church, the bank, the school, and the hotel would all be owned by the company. There would be no saloons. The streets would be cleaned by Pullman employees. The rents would be paid to Pullman. The gas in the lamps would be generated by a Pullman plant and metered through a Pullman pipe.

By 1885 Pullman had twelve thousand residents living inside this experiment. The model was so admired internationally that it won the Grand Prize at the 1896 International Hygienic and Pharmaceutical Exposition as the most perfect industrial town in the world.

Thirteen years after he built it, Pullman didn't own any of it. The Illinois Supreme Court ordered him to divest the entire town in 1898, ruling that the ownership of a complete civic infrastructure by a private manufacturing corporation was "incompatible with the theory and spirit of our institutions." Pullman had to sell every building that wasn't directly part of railcar production. The gas works went. The water plant went. The houses went onto the open market. The vertical integration that had produced the most admired industrial site of the 1890s lasted not quite one full business cycle.

The American hyperscaler industry is in the middle of trying to build it again.

The grid fight had a second act nobody was watching for

I have written a lot about the front of the grid fight. "The Grid Said No" covered the 11 GW of announced data center capacity sitting frozen because regional grid operators cannot deliver the interconnect on the calendar the financial models assumed. "The Permission Problem" covered the political-economy reversal in Loudoun County and the cascade of moratoriums it set off across thirty states. Both pieces ended at roughly the same observation: the binding constraint on the buildout is no longer technical. It is the willingness of a county commissioner, a state utility regulator, or a regional transmission organization to let you turn the racks on in the year you need them turned on.

What I underweighted in both pieces was the response.

Faced with a public grid that has discovered it can say no, the four largest hyperscalers spent 2024 and 2025 signing deals that look - when you stack them in one place - like the largest private utility buildout in American history. Microsoft signed a twenty-year purchase agreement with Constellation Energy to restart Three Mile Island Unit 1, the reactor that had been mothballed since 2019, dedicating the entire 835 MW output to a single corporate customer. Amazon Web Services bought Talen Energy's Cumulus campus sitting next to the Susquehanna nuclear plant, a $650 million deal for 960 MW of direct nuclear feed without ever touching the regional transmission grid. Google signed a 500 MW commitment with Kairos Power for the first commercial fleet of small modular reactors. Meta signed PPAs across four states for new natural gas turbine capacity dedicated entirely to single-campus loads. xAI installed thirty-five gas turbines on a single Memphis site - initially without air permits - to bring a frontier-scale training cluster online in months instead of the years a grid-tied build would have required.

The combined nameplate capacity sitting under these deals is somewhere north of 10 gigawatts of dedicated, single-customer generation, a footprint roughly the size of the nuclear fleet of France. None of it is on the public grid in the sense the public grid was designed for. The hyperscalers are not buying power from the utility. They are becoming the utility, and they are doing it on a calendar that the public utility cannot match.

The trade looks clean on a deal memo. The grid won't serve you for five years; you can have a dedicated reactor restart in two and a half. The substation queue is forty-eight months; the gas turbine vendor will ship in nine. Behind-the-meter generation moves you out of the queue you were losing and into a queue you can pay to skip. Every CFO presentation I have seen on this in the last six months treats the math as obvious.

The math is obvious. The thing the math omits is the part that matters.

What the deal memo does not say

When a manufacturing company owns the generation stack underneath its production sites, three things happen that do not happen when it buys the same power off the grid, and all three are showing up in the hyperscaler buildout right now.

The first is regulatory exposure. A regional utility builds a generation asset under a rate case approved by a state public service commission, and the rate-base recovery model spreads the cost and the regulatory risk across millions of customers. When Microsoft restarts Three Mile Island for itself, the rate case becomes a single-counterparty contract subject to whatever rules the NRC, FERC, and the relevant state commission decide to impose this decade. The rules are not stable. Pennsylvania, New Jersey, and Ohio have all introduced legislation in the last six months to either tax behind-the-meter loads at the same rate as transmission-level loads or to require dedicated generation deals to include a public-benefit contribution. None of those rules existed when the deals were signed. All of them are now real liabilities on the corporate balance sheet of the buyer, not socialized across a ratepayer class.

The second is operational complexity. A hyperscaler's data center operations team is, structurally, a software organization. It is extremely good at running fleets of homogenous compute, at automating failure recovery, at managing complex but well-understood control loops. It is not, by training, an operator of nuclear plants, gas turbines, or grid-scale battery installations. Talent for those roles does not transfer from the data center side; it transfers from the utility side, which has been shedding skilled operators for two decades and is itself short. The hyperscalers are now hiring across that gap, and they are hiring at a price that is starting to show up in the cost basis of the same regional utilities they bypassed. The labor market for a senior reactor operator is, as of this quarter, structurally tighter than the labor market for a senior site reliability engineer. That cost is not going down.

The third is political-economy exposure. The original argument for socializing grid investment was that the utility, as a regulated monopoly, absorbed the externalities - the emissions accounting, the water consumption, the noise complaints, the community impact - under a public framework with a public hearing. When the hyperscaler builds its own generation, those externalities do not vanish. They move onto the hyperscaler's site, the hyperscaler's environmental report, and the hyperscaler's PR budget. The Memphis turbines are the first version of this story to break into the national press. They will not be the last. The same county commissioners who discovered they could say no to a hyperscale campus will discover, on the same calendar, that they can say no to a hyperscale gas plant. Building your own generation does not exempt you from the political fight over generation; it makes you the protagonist of it.

This is the part the Pullman story actually rhymes with. Pullman did not lose the town because the gas works failed or because the houses were poorly built. He lost it because the act of owning the full vertical stack put him in a political relationship with the public that the public eventually refused to accept. Owning a town meant being the landlord during the recession, the wage-setter during the strike, and the rent-collector during the federal intervention. The vertical integration that looked like a moat in 1885 was a target by 1894. The hyperscalers are not in 1885. They are somewhere around 1892.

The architecture has a different answer

The reason this matters for the larger argument I keep making is that there is a perfectly good alternative, and it is the alternative this site has been pointing at for two years.

A 2 GW campus needs 2 GW of dedicated generation. It needs that generation in a single place, with single-site permitting, single-site water, and single-site political risk. A workload that is the same size, distributed across 200 sites at 10 MW each, needs 10 MW of generation per site. Ten megawatts is a load profile that the existing grid can absorb almost everywhere in North America without a substation upgrade, without a behind-the-meter generation deal, and without becoming the protagonist of a county commission meeting. Ten megawatts is the load of a mid-sized cold-storage facility. Nobody fights about cold-storage facilities.

This is not a marketing line. It is a thermodynamic property of the buildout. The reason the grid is fighting back, and the reason the hyperscalers are now reaching for the utility stack underneath them, is that hyperscale-class concentration of compute requires hyperscale-class concentration of power. Distribute the compute and the power problem decomposes into a series of problems each of which the existing system already knows how to solve. Concentrate the compute and the power problem aggregates into a single problem the existing system was specifically built not to solve at that scale.

The hyperscalers are picking the harder path because the inference inversion has not fully landed in their capex committees yet. The CFO calendar still treats a 2 GW campus as the unit of account. Until it stops treating it that way, the response to a hostile grid will continue to be vertical integration, and the response to vertical integration will be - on a delay of a few years, but reliably - the same response the Illinois Supreme Court gave Pullman. There is a part of the public infrastructure that the public will not let a single counterparty own outright, and electrical generation has been on that list for the better part of a century. The deals being signed this quarter are an argument that the list has changed. The political response over the next thirty-six months will determine whether the argument holds.

My bet is that it does not. Pullman did not lose because the buildout failed; the buildout was magnificent. He lost because the buildout produced a relationship between the company and the public that the public eventually voted against. That vote, in 2026, looks like a state legislature passing a behind-the-meter surcharge bill. It looks like a public service commission requiring single-counterparty generation deals to include rate-payer subsidies. It looks like a federal rule from the Treasury or the EPA changing the tax treatment of dedicated nuclear restarts. None of these are speculative. All of them are on legislative calendars right now, in jurisdictions where the same fight that produced the moratoriums in Loudoun produced the bills.

The hyperscaler answer to "the grid said no" was to build the grid themselves. The historical track record on that move, in the United States, is not encouraging. The thing that ended Pullman was not the depression of 1893. It was the discovery, by everyone outside the company, that the company had built something it was not entitled to keep.

Financing a 2 GW behind-the-meter buildout COULD work. But financing a buildout that does not require it would be even better.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

Originally published at Welcome Back to Pullman.

For Londoners, a Roman Bridge Still Determines Your Commute

David Aronchick — Fri, 08 May 2026 00:16:16 +0000

Around 50 CE, give or take a few years, a group of Roman military engineers picked a spot on the River Thames and bridged it. They picked the place they did because it was the narrowest practical crossing downstream of the marshes that lined the river's lower reach, with banks workable enough to anchor timber piers and high enough not to wash out at high tide. The bridge they built ran roughly 280 metres across the water on at least nineteen wooden pilings. On the dry, slightly elevated north bank where it landed, an opportunistic trading settlement took root, attracted to the only place for miles where you could reliably get from the south side of the river to the north on foot. They called the settlement Londinium.

The bridge has been rebuilt many times. The Roman timber structure was patched and replaced for centuries, then collapsed into disrepair after the Romans withdrew from Britain in 410 CE. The city itself was largely abandoned for the next two and a half centuries, until Alfred the Great refounded London in 886. The first stone bridge was begun in 1176 by a priest and architect named Peter de Colechurch and finished in 1209, three years after his death. That bridge, the famous Old London Bridge with shops and houses built along its length, eventually rising several stories tall, with severed traitors' heads on spikes at the south gatehouse, stood for over six hundred years. It was replaced in 1831 with John Rennie's stone arch design, which was itself replaced in 1973 with the present concrete-and-steel span that most Londoners walk across without thinking about it.

Each rebuild was on essentially the same site. Once you have built a city around a bridge, the bridge isn't where the bridge is. The city is where the bridge is.

The bridge story is binding even when nobody knows it

Almost every long-arc fact about modern London cascades from that one Roman engineering decision. The City of London, the financial district, the square mile with the bowler-hat-and-pinstripe stereotypes, sits where it sits because that's where the original bridge landed and where Roman commerce piled up around the crossing. Westminster grew separately, two miles upstream, because the medieval kings wanted physical distance between their royal seat and the merchants. The Tower of London was built next to the bridge specifically to control it. The East End and West End divide settled where it did because the prevailing wind blew industrial smoke eastward over centuries, depressing property values on the downwind side. The London Underground, when it was built starting in 1863, inherited the medieval street grid. Your commute today routes through that grid. The grid exists because the city's center settled where the bridge crossed. The bridge crossed where it did because of a tide table from two thousand years ago.

You can describe London accurately without knowing any of this. The city works fine. The Northern line still runs. Property prices in Hampstead are still higher than property prices in Stratford, and you can look up by how much without ever asking why. Most of the people who walk across London Bridge twice a day on their way to and from Bank station have never thought about the Romans, the marshes, or Peter de Colechurch. They don't need to. The city's shape is taken as given.

You only run into the bridge story when you try to change something. Try to propose a new river crossing in central London and you discover that every site you could pick is constrained by infrastructure that was placed because of the original crossing. Try to redirect a Tube line and discover that the geology of the City rules out anything but the routes that already exist, because the ground was tunneled and stabilised for the routes that already exist, because the routes were drawn to serve the medieval street pattern, because the medieval street pattern formed around the crossing. Every constraint you hit is downstream of a decision nobody remembers being made.

That is what a millennium of accumulated technical context does to a city. Most of it is invisible from the street, and all of it is binding the moment you try to do anything new.

Every dataset has a Roman bridge

Every dataset you have ever worked with has the same structure. There is a column on a table somewhere in your enterprise that exists because of a regulation that was passed in 2017 because of an incident at a competitor in 2014 because of a Senate hearing in 2013 because of a complaint from a single advocacy group in 2011. Three job-changes later, nobody at your company remembers any of that. The column is still there. Every model trained on the table inherits the column. The model has no idea why the column exists, but it learns to weight it anyway, because the column is in the data.

A schema you work with today was probably designed by a team that no longer exists, to support a use case that no longer matters, against a constraint that has since been repealed. The schema is internally consistent. The data flowing through it is internally consistent with the schema. An LLM that reads the data produces internally consistent answers about it. None of that consistency tells you whether the conditions that justified the original design still hold, because the conditions are not in the data. They are in the meeting notes nobody saved, the email thread that got archived in 2018, the SOC 2 attestation that was renewed three times before anyone questioned the assumption underneath it.

Most of the time the cascading context doesn't matter. Like the Northern line, the system works. The model returns reasonable answers, the dashboards load, the forecast goes out to investors, and nothing breaks. Until something changes. A regulator asks why the model is treating two customer segments differently and the answer is that the segmentation was built in 2019 against demographic categories that have since been ruled discriminatory. A new product manager asks why the recommendation engine biases toward older content and the answer is that the original training data was filtered by an engineer who wanted to remove a category of spam in a way that incidentally also removed everything posted after a certain date. Every constraint you hit is downstream of a decision nobody remembers being made.

Stanford's 2026 AI Index puts hallucination rates across the leading frontier models in a band stretching from 22% to 94%, depending on the domain and the test. The reflexive industry response is to point at the model, ask for better fine-tuning, better RAG, better evals, and that response is wrong in roughly the same way as proposing a better Tube line without acknowledging the geology. The hallucinations aren't really coming from the model. They're coming from the fact that enterprise data is a city with no bridge story, and the model is being asked to interpret the city without the history. It does its best. Its best is wrong about a quarter of the time and sometimes very wrong. The fix isn't a smarter tourist. The fix is to keep the bridge story attached to the data while the data is moving through the pipeline, instead of stripping it at every hop.

The pipeline strips context aggressively

Consider what a normal AI pipeline does to historical context.

Source data is extracted from a system of record into a staging area. Whatever source-system-specific metadata existed (the user who created the row, the version of the upstream schema, the policy that required the field to be populated) is dropped or reduced to a vendor-neutral representation that loses most of the meaning. The data is transformed and joined with other extracts in the warehouse, where any conflicts between the sources are resolved silently by whichever ETL job runs last. The result lands in a feature table. The feature table is consumed by a model, or chunked and embedded for retrieval, or sometimes both. By the time the embeddings are sitting in the vector index, the only remaining pointer back to the original source is a row ID in a Parquet file in object storage. The historical conditions, the authority chain, the regulatory rationale, the schema evolution, all of it is gone.

When a user asks the model a question, the retriever fetches chunks based on geometric similarity in the embedding space. Geometric similarity does not preserve provenance. The retriever has no way to surface the fact that one chunk was authored by a regulator and another by an intern, or that the regulator's chunk supersedes the intern's chunk, or that the intern's chunk was written under a policy that was repealed three months ago. The model reads both, treats them as roughly equivalent inputs, produces an answer that averages them, and cites both chunks. The citation looks rigorous because the citation has nothing to check itself against.

This is the failure mode I wrote about in The Only Guarantee Is Your Catalog Will Be Wrong. Eventually. and again in The Missing Part of the Pipeline. The structural answer is to wrap the bridge story onto the data at the moment of ingest, with claim-level granularity, signed and immutable, and let it ride with the data through every downstream transform. Provenance has to be a property of the artifact, not a layer reconstructed afterward by a catalog crawling artifacts that have already lost their context. Every downstream consumer inherits the wrap for free. The model reading the data can tell that the regulator's chunk supersedes the intern's chunk because that fact is in the manifest the chunk carries with it. The SLSA specification defines this primitive for software builds. The same primitive is what the data world has been missing.

Cities are easier to read than data because they are physical

Cities have one big advantage over datasets, which is that they are physical. London Bridge is still there. You can see it. You can stand on it. You can look at it from the river and notice that the modern span is in suspiciously the same place as the medieval one and ask why, and the answer is right there for anyone who wants to follow the chain. Even if nobody bothered to write the bridge story down, the city wears it as a physical fact.

Data has the same kind of inheritance, but invisible. The schema does not announce that it was designed in 2017 against a regulation that no longer exists, the model weights do not announce that they were trained on a corpus a since-departed engineer happened to filter according to his strong opinions about spam, and the retrieval index does not announce that one of its chunks is six years stale and authored by somebody whose role got eliminated in the last reorg. The cascading historical decisions are still in there, still doing the work of constraining the system, but you cannot see any of it by looking at the system from the outside.

The only way to make the inheritance legible is to refuse to lose it in the first place. Wrap the bridge story onto the data while the data is being born. Sign the manifest. Carry it forward. When the data is consumed by an LLM, hand it the manifest along with the data, so the model can tell the difference between a current authoritative source and a stale auxiliary one. When the model produces an answer, have the answer cite not just which chunk it came from but which version of which source under which authority at which point in time. This is not abstract. The components for it exist as discrete primitives in modern data infrastructure. What's missing is the integrated layer that combines them into a continuous bridge story for every claim the system makes.

Brian Arthur's work on path dependence showed decades ago that systems with increasing returns tend to lock in early choices for centuries, sometimes longer. The Davis-Weinstein analysis of Japanese cities after WWII bombing showed that even when you flatten a city to rubble, it tends to grow back in roughly the same places, because the underlying locational logic that put the city there in the first place is still in force. London's bridge is that kind of artifact. The Thames is the width it is, the banks are the shape they are, the tides behave the way they behave, and the Romans noticed in 50 CE that all of those things together made one specific spot the only sensible place to bridge. That fact has been load-bearing ever since.

Your enterprise data has the same kind of underlying logic, except none of it is visible from the outside. The schemas, the tables, the dashboards, and the trained models were all designed for reasons that were correct at the time, by people who understood the constraints they were operating against, with a specific regulation in mind and a specific customer expectation in mind that made sense in the year the decision got made. The decisions persist long after the reasons stop applying, and the model trained on the result is operating on a city plan that does not include the bridge.

You can fix this. The components are sitting on the shelf in modern data infrastructure. Wrap the data at ingest, sign the manifest, carry the bridge story through every downstream transform, and the LLM finally reads a substrate that knows where it came from. Stop making AI guess at a city it cannot see.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.

Originally published at For Londoners, a Roman Bridge Still Determines Your Commute.

The Permission Problem

David Aronchick — Wed, 06 May 2026 18:27:58 +0000

Let's talk about Loudoun County, Virginia.

If you don't work in infrastructure, you've never heard of it. If you do, this is THE place. Somewhere between 60% and 70% of the world's internet traffic routes through facilities sitting in this one Northern Virginia county, and for most of the last decade Loudoun was also the most permissive jurisdiction in the country for hyperscale construction. The Board of Supervisors approved campuses on what was effectively a rubber-stamp cadence, the substation costs got socialized into the broader Dominion Energy rate base, the county collected the property tax revenue, and most of the AI buildout from 2022 through 2024 was financed against the assumption that Loudoun was the median, not the outlier.

This quarter, Loudoun has more active moratorium proposals on its docket than any comparable jurisdiction in the country. That reversal happened in eighteen months. It is happening for reasons that are going to keep happening, in places nobody had on their 2026 risk register.

The bottleneck nobody priced into a 2024 financial model was never going to be technical, even though most of the discourse acted like it would be. Compute is fine, NVIDIA shipped on time, the networking gear arrived, the cooling works in the lab and at scale, and not one of those things is what is going to keep your 2026 workload from coming online. The thing that is going to keep it from coming online is whether a county commissioner, a state public utility commission, or a regional grid operator will let you turn the racks on in the calendar year you actually need them turned on. That answer is moving in real time, and it is moving in the wrong direction for the buildout that just got financed.

A 2 GW campus is a financeable thing on paper. It is a five-year fight in dirt, and the fight is what is changing.

The grid-skeptics had the diagnosis right

The folks who have spent the last two years warning that centralized AI was going to slam into grid limits got the diagnosis exactly right, and at this point I would just like to say sorry to anyone I argued with about it in 2024. Data centers now account for roughly half of all new US electricity demand. Global AI-related electricity consumption is on track for around 1,000 TWh by the end of 2026, which is a midsize industrialized country's worth of electricity. Treating any of this as a footnote, which most of the industry did until about a year ago, was a category error.

But then the same crowd keeps handing me a prescription that does not survive contact with the actual political-economy environment, and that is where the conversation falls apart.

Will isn't the problem. Coalition is.

The fix-the-grid argument assumes that the engineering exists, the financing exists, and the only thing missing is political will. That is half right, in the way that "all I need to climb Everest is a good attitude" is half right. The engineering is mature, DOE has the modernization roadmap, FERC has the interconnection reform proposal, the transmission corridors are mapped, the storage technology is production-ready, demand-response is running in pilot, and none of this is mysterious. What is actually missing is not will. It is coalition, and coalition is the thing that does not show up in an engineering roadmap.

Transmission siting is a state-level fight in most US jurisdictions, and most of the relevant states do not have a clean coalition through it. New generation siting requires winning a NIMBY fight, an environmental review, in a lot of places a tribal sovereignty fight, and increasingly a ratepayer revolt, all stacked on the same project. Substation siting plays out at the county and municipal level, where the constituency that benefits from a hyperscale data center load (a hyperscaler in another time zone) has roughly zero votes in the relevant elections, and the constituency that absorbs the cost (the residential ratepayer, the school district worried about its assessment, the homeowner two miles upwind) has roughly all of them. That is not a failure of imagination. It is a vote count.

I have watched a lot of my friends in this industry get frustrated with voters about this, which I understand and which I also think is short-sighted. The voters are not being unreasonable. They are being asked to underwrite a buildout whose direct cost they pay, whose direct benefit they do not see, and whose externalities (the noise, the water, the visual blight, the higher bills) they live next to. Of course they are saying no. The surprising thing is not that they finally noticed, it is that we expected them not to.

State PUCs noticed. Several have moved hyperscale data center loads into separate rate classes specifically to insulate residential ratepayers from the cost of expansion, and almost no AI press picked it up, which is a miss because once the rate base splits, the financing model that made hyperscale campuses cheap collapses, the hurdle rate goes up, and the build cadence slows. None of this is anyone being unreasonable. It is the cost of asking anyone to be reasonable getting priced in.

"But hyperscalers will scale through it." Are you sure?

The other prescription, the one coming out of the labs and the hyperscalers themselves, is that announced capacity will roughly track delivered capacity, the way it did in 2018 and 2019 and 2020 and 2021. That was a defensible extrapolation through the end of 2024, stopped working visibly in 2025, and is now in open contradiction with the data.

Loudoun is not a one-off. Suburban Phoenix and several Texas exurbs have either passed moratoria or surfaced moratorium proposals into active hearings, and Northern Virginia substation projects that were routine approvals five years ago are now multi-year political fights. Two stories from the last couple weeks tipped me off that the political turn just crossed a threshold I had not seen yet. CNN ran a piece on April 23 titled "There are fixes for AI's toll on the power grid. Here's why they're not happening." Three days earlier, Fortune published polling showing Americans now associate AI infrastructure with rising electricity bills and have soured on AI as a category as a result. Read the bylines. Notice where those pieces ran, because CNN and Fortune are not Common Dreams, and the political turn against centralized AI just migrated out of the activist fringe and into the centrist business and political press, which is the part of the spectrum that most reliably foreshadows where actual zoning votes are going to land in the next election cycle.

So which side is right? Both, kind of, and also neither in the way that actually matters for the next twenty-four months. The fix-the-grid argument resolves on a presidential-term timeline. The hyperscaler-scale-out argument is hitting the wall right now. The actual workload, the stuff being trained and served and shipped by product teams who do not care about either argument, has to run somewhere, and where it runs is wherever the substation is already humming.

Telco edge: the buildout that already happened

There is already a huge pile of capacity sitting in places nobody is having moratorium fights about. Cell tower compounds. Regional colo footprints. Retired industrial facilities with their substation tie-ins still intact. Telco central offices that were sized in 1996 for a voice and broadband workload that has since contracted by an order of magnitude. The substations are paid for, the easements are paid for, the cooling is roughly fine, and the community license, which is the hard part of all of this, was granted thirty years ago by a public that has long since moved on to caring about other things.

NVIDIA put a number on this at GTC in March: roughly 100,000 telco data center sites globally, with 100 GW of spare capacity already energized. HPE's distributed AI factory rollout approaches the same problem from the enterprise side. The two of them are converging on the answer that has been sitting there the whole time, which the discourse has been politely ignoring because it is not as exciting as building a new 2 GW campus in cornfield Wisconsin.

There is a reflex in this industry, especially among people who learned their economics on the AWS scale curve, to dismiss the whole telco-edge category as too small, too inefficient, too logistically annoying to be the actual answer. That dismissal was defensible when the hyperscale alternative was clearing on a four-year cadence. It is not defensible when the alternative is a 2028 FERC study cycle and a Loudoun moratorium hearing on the same docket. A workload that runs at slightly worse unit economics on permitted infrastructure beats a workload that does not run at all, and the economics that looked bad against a 2024 spreadsheet look fine the moment the comparison case becomes zero.

I made the structural case for this in Six Million Cell Towers Walk Into a Data Center, and the incumbents have started making the argument for me, which has historically been the moment a position quietly graduates from contrarian to obvious.

So what do you actually do about any of this

For three years the AI infrastructure debate ran at the engineering layer, in some combination of NVIDIA versus AMD, hyperscaler versus neocloud, and centralized versus federated, in roughly that chronological order. None of those framings was wrong on its own terms. They were operating one layer above the constraint that is now actually binding.

The constraint that is now actually binding is whether your load gets to come online in the calendar year you need it, and the answer is unevenly distributed across US geography in ways the planning process has not caught up to. Some sites have the permission. Most do not. The architecture that wins the next two years is the one that pays attention to which is which and routes the workload accordingly.

If your 2026 inference is sitting in a FERC interconnection queue with a 2029 study cycle, that capacity does not exist for you, and the same is true if your training run is waiting on a substation transformer with an 18-month lead time. Anything else you have planned that depends on Loudoun voting yes is on a similar timeline, and the timeline is worse than your roadmap admits.

Loudoun is not voting yes.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.

Originally published at The Permission Problem.

The Brownian Ratchet for Data

David Aronchick — Fri, 23 Jan 2026 00:35:31 +0000

Monday I wrote about how multiclaude and GasTown converged on nearly identical primitives for multi-agent orchestration. The key insight wasn't about prompts or models or agent personas. It was about infrastructure: CI is the ratchet. Let chaos reign. Multiple agents, overlapping work, duplicated effort, whatever. As long as you have a mechanism that only captures forward progress, you're good.

That phrase has been rattling around my head ever since. Because here's the thing: we have this for code. What's the equivalent for data?
The Missing Ratchet
CI transformed software development by giving us a one-way gate. Code either passes or it doesn't. No negotiations, no exceptions, no "we'll fix it later." The ratchet clicks forward, and it never clicks back.

Data has no such mechanism.

Oh, we have tools. We have great expectations (pun intended). We have dbt tests and schema validators and anomaly detectors. But none of them function as the arbiter-the single, uncompromising source of truth that says "this data is real now, and we're never going backward."

Instead, we have... hope? Process? Tickets that say "data quality issue" that sit in someone's backlog for three sprints while the dashboard keeps serving numbers that everyone knows are wrong but nobody can prove?
What Would a Data Ratchet Look Like?
Let's steal the multiclaude architecture and apply it to data:

Code Ratchet
Data Ratchet

CI tests
Schema validation + semantic checks

Passing tests
Data meeting quality thresholds

Merged PRs
Verified, immutable records

Git history
Data lineage with provenance

Multiple agents
Multiple validators / transformation paths

The principle is the same: chaos is fine, as long as we ratchet forward.

Multiple data sources can feed into your system. They can be messy, inconsistent, formatted in ways that make you question whether the upstream team has ever heard of ISO 8601. That's the Brownian motion: the random thermal energy of the real world generating data in a thousand incompatible ways.

But the ratchet, the verification layer, only lets validated data through. And once it's through, it's permanent. Immutable. Part of the record.
The Four Components
I think a data ratchet needs four things:

The Pawl: Schema as Contract JSON Schema (or Avro, or Protobuf, whatever floats your boat) isn't just documentation. It's the pawl that prevents backward motion. Data either conforms or it doesn't. No partial credit.

Here's what a schema-as-pawl actually looks like:
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "SensorReading",
"type": "object",
"required": ["device_id", "timestamp", "value", "unit"],
"properties": {
"device_id": {
"type": "string",
"pattern": "^[A-Z]{2}-[0-9]{6}$"
},
"timestamp": {
"type": "string",
"format": "date-time"
},
"value": {
"type": "number",
"minimum": -273.15
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit", "kelvin"]
}
},
"additionalProperties": false
}

Notice additionalProperties: false. That's the pawl. You can't sneak extra fields through. You can't send "value": "hot" instead of a number. You can't omit the timestamp and promise to fill it in later.

But here's where most systems fail: they treat schema validation as a warning, not a wall. "Schema violation detected, logging and continuing." That's not a ratchet. That's a turnstile with a broken lock.

A real data ratchet rejects non-conforming data. Full stop. The data can go back to the source, get transformed, get remediated, whatever it needs to do. But it doesn't get through until it conforms.

The Wheel: Idempotent Checkpoints In multiclaude, git worktrees give each agent isolation. If an agent's work fails, it fails in its own branch. The main branch (the ratcheted progress) stays untouched.

Data pipelines need the same thing: checkpoints that are idempotent and isolated. If a transformation fails, you can retry from the last checkpoint without corrupting the verified data downstream.
class CheckpointedPipeline:
def init(self, checkpoint_store: str):
self.checkpoint_store = checkpoint_store

def process_batch(self, batch_id: str, records: list[dict]) -&gt; str:
    # Check if we already processed this batch
    checkpoint = self.load_checkpoint(batch_id)
    if checkpoint and checkpoint[&quot;status&quot;] == &quot;completed&quot;:
        return checkpoint[&quot;output_path&quot;]  # Idempotent: return existing result

    # Process in isolation (write to temp location)
    temp_path = f&quot;{self.checkpoint_store}/pending/{batch_id}&quot;
    validated = []
    for record in records:
        if self.validate(record):
            validated.append(record)
        else:
            self.quarantine(record, batch_id)  # Don&apos;t lose it, just don&apos;t let it through

    self.write_records(temp_path, validated)

    # Only after success: commit the checkpoint
    final_path = f&quot;{self.checkpoint_store}/verified/{batch_id}&quot;
    self.atomic_move(temp_path, final_path)
    self.save_checkpoint(batch_id, {&quot;status&quot;: &quot;completed&quot;, &quot;output_path&quot;: final_path})

    return final_path

The key moves: write to a temp location first, only move to the verified path after success, and the checkpoint makes retries safe. If the process dies mid-batch, we start over. No partial state leaking into the verified dataset.

Most pipelines I've seen treat state as something that happens to them rather than something they manage. They're stateless in theory and stateful in practice, which is the worst of both worlds.

The Arbiter: Automated Verification with Teeth Here's the multiclaude rule that matters: agents are forbidden from weakening CI to make their work pass.

Translate that to data: no one can weaken the validation rules to make bad data pass. Not the data team, not the business stakeholder with a deadline, not the executive who needs the dashboard updated yesterday.

What does "CI for data" actually look like? Something like this:

data-ci.yaml

name: Data Quality Gate

on:
data_ingestion:
sources: ["sensor-feed", "partner-api", "user-uploads"]

jobs:
validate:
steps:
- name: Schema Validation
run: |
jsonschema --instance ${{ inputs.data_path }} \
--schema schemas/${{ inputs.source }}.json
fail_on_error: true # This is the ratchet. No exceptions.

  - name: Semantic Checks
    run: |
      python checks/semantic_validator.py \
        --data ${{ inputs.data_path }} \
        --rules rules/${{ inputs.source }}.yaml
    # Example rules:
    # - timestamp must be within last 24 hours
    # - device_id must exist in device registry
    # - value must be within 3 std devs of rolling mean

  - name: Lineage Recording
    if: success()
    run: |
      record-lineage \
        --input ${{ inputs.data_path }} \
        --schema-version ${{ inputs.schema_hash }} \
        --validator-version ${{ github.sha }} \
        --output verified/${{ inputs.batch_id }}

on_failure:
steps:
- name: Quarantine Bad Data
run: |
move-to-quarantine ${{ inputs.data_path }} \
--reason "${{ job.failure_reason }}"
- name: Alert Source System
run: |
notify-upstream ${{ inputs.source }} \
--batch ${{ inputs.batch_id }} \
--errors ${{ job.validation_errors }}

The critical bit is fail_on_error: true with no escape hatch. No continue-on-error. No "warn and proceed." The data either passes or it goes to quarantine.

This is culturally difficult. It requires the same organizational commitment that "we don't ship if tests fail" required for software teams. But it's the only way the ratchet works.

Reproducibility: The Secret Ingredient There's one more piece that makes the code ratchet work: reproducibility. When CI fails, you can reproduce the failure. When it passes, you can reproduce the pass. Same inputs, same outputs, every time.

Data systems are notoriously bad at this. The pipeline that worked yesterday fails today because someone changed an upstream schema. Or because the source system had a hiccup. Or because Mercury is in retrograde. (I've debugged all three. The Mercury one was actually a timezone issue in a system named "Mercury." I wish I was kidding.)

A real data ratchet needs what I'd call a "usability signature":
{
"batch_id": "2026-01-22-sensor-feed-042",
"verified_at": "2026-01-22T14:32:01Z",
"input_hash": "sha256:a1b2c3d4...",
"schema": {
"name": "SensorReading",
"version": "2.1.0",
"hash": "sha256:e5f6g7h8..."
},
"validators": {
"semantic_checks": "v1.4.2",
"anomaly_detector": "v0.9.1"
},
"result": {
"status": "passed",
"records_in": 10482,
"records_verified": 10479,
"records_quarantined": 3
},
"output_path": "verified/2026-01-22/sensor-feed-042.parquet",
"output_hash": "sha256:i9j0k1l2..."
}

This signature is an artifact, not just a log line. You can take this signature, grab the input data by its hash, run the exact versions of the validators, and you'll get the same result. If you can't do that, you don't have a ratchet. You have a coin flip.
The Uncomfortable Implication
Here's what this means in practice: a lot of data that's currently flowing through your systems wouldn't make it through a real ratchet.

That's not a bug. That's the point.

The Brownian ratchet works because it's uncompromising. The pawl doesn't care that you really need this data for a quarterly review. It doesn't care that the source system "usually" sends valid records. It doesn't care about your deadline.

CI transformed software quality not by being smart, but by being stubborn. It created a culture where "works on my machine" stopped being an excuse because there was an objective arbiter that didn't care about your machine.

Data needs the same stubbornness. The same willingness to say "no" and mean it.
What This Looks Like in Practice
I've been thinking about this in the context of what we're building at Expanso: intelligent data pipelines that can process data at the edge. The edge is where the Brownian motion is strongest. Sensors, devices, user inputs, all generating data in a thousand formats with a thousand failure modes.

The traditional answer is to centralize. Pull everything to a data lake, clean it up, validate it there. But that's expensive, slow, and loses context. By the time you've moved the data, you've lost the ability to remediate at the source.

What if the ratchet lived at the edge? Validation happens where data is generated. Non-conforming data gets rejected immediately, while there's still context to fix it. Only verified data propagates upstream.

That's the vision. Not a single central ratchet, but a distributed network of ratchets. Each one small and stubborn. Each one clicking forward, never back.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

Originally published at Distributed Thoughts.

The Brownian Ratchet and the Chimpanzee Factory

David Aronchick — Tue, 20 Jan 2026 00:34:00 +0000

Two weeks ago, Steve Yegge released GasTown, a multi-agent orchestrator he describes as "an industrialized coding factory manned by superintelligent chimpanzees." A few days later, Dan Lorenc quietly pushed multiclaude, built on what he calls the "Brownian Ratchet" principle: chaos is fine, as long as we ratchet forward.

While the projects are separate, Dan says he was deeply inspired by Gas Town. However, they, and many others like them, landed on almost identical foundational architecture: detached UI for observability, git worktrees for isolation, external state persistence, and CI as the final arbiter. That convergence tells us something important about where agent tooling is heading.
The Problem Both Solve
Running one Claude Code instance is straightforward, but running twenty in parallel on the same codebase is a distributed systems problem. The challenges are familiar to anyone who's operated infrastructure at scale: agent sessions crash, work gets duplicated, changes conflict, and state disappears when processes restart. Without proper isolation, a single runaway agent can corrupt shared resources, and without observability you can't debug what's happening. If state doesn't persist, progress evaporates the moment something fails.

In source code, people saw this same problem (lots of people working on the same thing), and solved it incrementally with things like SVN, and then Git (with many others as well).

Every multi-agent orchestration system has to answer these questions about multiple things working on a single thing, and what's interesting is watching how different systems answer them.
Two Philosophies, Same Primitives
GasTown takes the comprehensive approach, with seven distinct agent roles that divide responsibilities across the system. The Mayor coordinates overall work, Polecats handle ephemeral tasks, the Refinery manages merge queues, and so on through Witness, Deacon, Dogs, and Crew. Work flows through what Yegge calls the MEOW stack (Molecules, Epics, Work orders), with state persisting through git-backed "hooks" and the Beads memory framework. Agents maintain persistent identities that survive session crashes via the GUPP principle: "If there is work on your hook, YOU MUST RUN IT." This is ... confusing ... but i have to respect explicitly naming everything. Gives you an unequivocal way to know what (and who) is doing what, at the cost of a lot of UX affordance up front.

multiclaude takes the minimalist path with just three roles: a supervisor that coordinates, workers that execute tasks, and a merge-queue agent that handles CI. State lives in a JSON file and the filesystem, communication happens through simple message passing, and the philosophy is explicit: "Trying to perfectly coordinate agent work is both expensive and fragile. Instead, we let chaos happen and use CI as the ratchet that captures forward progress."

The rhetoric differs dramatically between the two projects. Yegge's documentation reads like a manifesto, complete with warnings that you shouldn't use GasTown if you "care about money" or are "more than 4 feet tall." Lorenc's README is Unix-philosophy spare, with clean diagrams and matter-of-fact explanations. But underneath the different personalities, you find the same primitives.

Primitive
GasTown
multiclaude

Process isolation
tmux windows
tmux windows

Code isolation
git worktrees
git worktrees

State persistence
Git-backed hooks
JSON + filesystem

Quality gate
CI (automated merging)
CI ("the ratchet")

Observability
Attach to any session
Attach to any session

Both folks recognized that you can't just spawn Claude instances and hope for the best. You need boundaries.
What the Convergence Reveals
When two experienced engineers arrive at the same architectural primitives, that's signal worth paying attention to. It suggests these aren't arbitrary choices but structural requirements for the problem space.

Isolation requires more than process boundaries. Both projects use git worktrees rather than just separate directories because a worktree gives each agent its own branch, its own working copy, and its own commit history. Conflicts become merge conflicts, which git already knows how to surface, and the blast radius of any single agent is bounded by what it can do to its own worktree.

Observability can't be an afterthought. Both chose tmux as the primary interface rather than a web dashboard or log aggregator. A terminal multiplexer lets you attach to any agent's session, watch it work, and intervene if needed. This is distinctly different from how most "AI agent frameworks" approach the problem, with their emphasis on structured outputs and API-driven orchestration.

State must survive failures. GasTown invests heavily in crash recovery through git-backed hooks while multiclaude keeps it simpler with filesystem persistence, but both reject the idea of ephemeral agent state. When a session dies, the work shouldn't die with it.

CI becomes the coordination mechanism. In both systems, CI isn't just a quality check but the arbiter of what counts as progress. Lorenc is explicit: "If it passes, the code goes in. If it fails, it doesn't. The automation decides." Yegge's Refinery agent serves the same function, and this approach shifts coordination from real-time synchronization (expensive, fragile) to asynchronous validation (robust, scalable).
The Deeper Pattern: Scoped Autonomy
Strip away the specific implementations and you find a design pattern emerging for AI agent systems: scoped autonomy with external persistence. Give agents freedom to act within clear boundaries, let them fail without cascading damage, capture successful outcomes permanently, and accept that coordination is expensive and often unnecessary if your ratchet mechanism is good enough.

This isn't a new idea. It's how we've learned to build reliable distributed systems over the past two decades, and the insight here is that agent orchestration is distributed systems with the same principles applying. Kubernetes asks "Is it running?" and reconciles toward desired state while GasTown asks "Is it done?" and persists completed work. Both are control loops operating over unreliable workers, and both accept that perfect coordination is impossible and design around it.
Where They Diverge: Single-Player vs. MMORPG
The most interesting philosophical difference isn't about orchestration complexity but about the human model.

Lorenc frames multiclaude explicitly: "Gastown treats agents as NPCs in a single-player game. You're the player, agents are your minions. multiclaude treats software engineering as an MMORPG. You're one player among many."

In multiclaude, your workspace persists. You spawn workers, go to lunch, come back, and check what merged while you were away. Other humans can have their own workspaces on the same repo, and the system keeps running when you're not watching.

GasTown is designed around intensive engagement. Yegge describes watching 20-30 agents in parallel, making $100/hour decisions about what work to greenlight, experiencing "palpable stress" as the system runs at speeds too fast to comprehend. It's a powerful multiplier for an engaged operator rather than a fire-and-forget system.

Neither model is wrong since they're optimizing for different workflows, but the MMORPG framing points toward something important: these systems need to work when humans aren't actively supervising.
What This Means for the Industry
We're watching the orchestration layer crystallize in real time, and the patterns that emerge now will shape how agent systems get built for years.

The "19-agent trap" (simulating an org chart with Analyst → PM → Architect → Dev → QA handoffs) is giving way to operational models where agents have specific, bounded roles. The emphasis shifts from elaborate prompting frameworks to infrastructure primitives: isolation, persistence, observability.

The tooling will mature as costs drop. Right now, GasTown burns $100/hour in tokens, partly because the models are expensive and partly because the coordination overhead is high. Both factors will improve, and the architectural patterns being established now will outlast the current pricing structure.

For teams thinking about agent infrastructure, the lesson isn't "adopt GasTown" or "adopt multiclaude" since both are weeks old and explicitly experimental. The lesson is to watch what primitives they converged on, because if you're building agent systems you'll probably need them too: git worktrees for isolation, something tmux-like for observability, persistent state that survives session failures, and CI or some equivalent as the ratchet that captures forward progress.

The chimpanzee factory and the Brownian ratchet arrived at the same answer. That's worth paying attention to.

Repos:
- GasTown: github.com/steveyegge/gastown
- multiclaude: github.com/dlorenc/multiclaude

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

NOTE: I'm currently writing a book based on what I have seen about the real-world challenges of data preparation for machine learning, focusing on operational, compliance, and cost. [I'd love to hear your thoughts**](https://github.com/aronchick/Project-Zen-and-the-Art-of-Data-Maintenance?ref=distributedthoughts.org)!**

Originally published at Distributed Thoughts.

The Upstream Problem: Why Context Graphs Are Starving

David Aronchick — Sat, 17 Jan 2026 00:33:27 +0000

Foundation Capital just published what they're calling AI's trillion-dollar opportunity: context graphs. They argue that enterprise value is shifting from systems of record (Salesforce, Workday, SAP) to systems of agents. The new crown jewel isn't the data itself. It's the context graph: a living record of decision traces stitched across entities and time, where precedent becomes searchable.

They're right about the destination. But Greg Ceccarelli's response on LinkedIn caught something important that their framing misses. Foundation Capital focuses on capturing decisions at execution time. That matters, but it's the last mile. The first mile is still bleeding out.
The Telephone Game (But With Developers)
Decisions don't originate at execution time. They originate in conversations.

A PM pattern-matches across customer interviews. Engineering debates constraints in Slack. A VP makes a call on a Zoom that nobody documents. By the time any of this hits a system of record, the context has been compressed, lossy-encoded, and re-interpreted three times. It's a game of telephone where the prize is a barely articulated card in your Kanban roadmap.

Recording meetings is table stakes now. The raw material exists. But most of it vanishes. It's searchable in theory and useless in practice. You can find that the decision was made, but you can't find why it made sense given everything else that was happening at the time.

Jamin Ball's piece "Long Live Systems of Record" pushed back on the "agents kill everything" narrative, arguing that agents don't replace systems of record, they raise the bar for what a good one looks like. I think he’s right, but the problem is no one is the voice for the downstream consumers. The reasoning, the exceptions, the context that justified a decision in the moment isn’t in any form that a human (let alone an agent) can find or consume. That's what's missing.

Context graphs need to be fed. The feed is conversations, and, right now, conversations evaporate.
The Same Problem, Worse, in Data
Greg's framing focuses on software development, and that's where his company SpecStory and their new Intent product are building. I think these are awesome, and deserve a lot of attention. In fact, so much so that I want to take it further. Software development is just one domain where decisions get lost upstream.

Data pipelines, our world, are another, and arguably worse.

When a data engineer decides which fields to drop during transformation, how to handle null values in a critical column, why a particular join strategy was chosen over another, what "clean" means for this specific dataset... where does that reasoning live? In a PR comment that gets archived. A Slack thread that disappears. Someone's head who leaves the company.

The data observability market has exploded. Gartner estimates data observability will be a $2.5B+ market by 2027. But all of it focuses on detecting problems after they happen. The upstream intent, why the pipeline was designed this way, what tradeoffs were considered, what the original constraints were, remains uncaptured.

Another favorite company of mine,Great Expectations, does a great job capturing what should be true. And dbt moves documentation closer to the code. And we have standards

, for example, captures the what of transformations. But almost nothing captures the WHY.

When an ML model makes a bad prediction, you can trace back to the training data. But can you trace back to why the training data was prepared that way? Who decided to impute missing values with medians instead of dropping rows? What was the conversation that led to that feature engineering choice? What did the team know at the time that isn't written down anywhere?

The decision trace doesn't exist because nobody captured it when it happened.
Intent Has Locality
This connects to something I've been thinking about for years. Intent has locality, just like data.

The richest context about a decision exists at the moment it's made, in the place it's made. Move it somewhere else, a different system, a different time, a summary written later, and you lose fidelity. This is true whether you're moving bytes across a network or moving reasoning into documentation.

Think about what happens when you try to document a decision after the fact. You're reconstructing. You remember the outcome but not the three alternatives you considered. You remember the constraint that mattered most but not the secondary factors that shaped the final call. You remember that someone raised an objection but not exactly what shifted the conversation.

The further you get from the moment of decision, the more context you lose. And unlike data, you can't just store a copy closer to where it's needed. The moment passes. The reasoning evaporates. What remains is the artifact without the intent.
What SpecStory Is Building
This is why what Greg and the SpecStory team are building with Intent matters. They started where decisions turn into code: the conversation between developers and coding agents. Intent records every exchange with Claude Code, Cursor, GitHub Copilot, Codex, Gemini. The transcript of how software actually gets built.

But as they asked where the intent came from, the answer kept pointing upstream. Team calls. Architecture discussions. Pairing sessions. The decisions that happen before anyone opens an IDE.

Their solution has three layers:

Capture: Every agent prompt and IDE session, recorded automatically. Not just the code that got written, but the back-and-forth that produced it.

Arena: Real-time collaboration with automatic decision extraction. Not verbose summaries nobody will read. The actual decision linked to the exact moment in the conversation.

Repo: Decisions versioned alongside your source code. Consumable by humans and agents. Searchable forever.

Full context lineage: Team discusses → Decision extracted → Agent builds → Session reasoning preserved → Code ships. Every line of code traceable back to the exchange where the decision was made.

That's the upstream feed layer context graphs need. The bridge from conversation to context to code.
The Parallel Problem Nobody's Solving for Data
The same pattern applies to data infrastructure, and the gap is even wider.

Here's an example I come back to constantly. You're looking at point-of-sale data from a retail chain, and one store shows zero transactions for six hours. What happened?

Maybe the system wasn't connected. Maybe there was a hurricane. Maybe it was midnight and the store was closed. Maybe there was a police action in the area. Maybe the pipeline is connected but stopped running. Maybe someone unplugged the wrong cable during a renovation.

The data looks identical in every case: zeros. But the appropriate response is completely different. If it's a hurricane, you adjust your forecasts and check on your employees. If it's a pipeline failure, you fix the pipeline and backfill the data. If it's midnight, you do nothing because everything is working correctly.

The "what" is the same. The "why" determines everything that matters.

This is the context gap in data infrastructure. Data lineage tools tell you what transformations happened. They don't tell you why someone chose that approach over alternatives. Data catalogs describe what datasets contain. They don't capture the discussions that shaped how those datasets were structured. Data quality tools flag when something looks wrong. They can't explain what "right" was supposed to mean based on the original requirements conversation.

Every data team has experienced this: you inherit a pipeline, something breaks, and you spend days reverse-engineering decisions that took the original author five minutes to make. The 2024 Stack Overflow survey found developers spend 30%+ of their time understanding existing code. For data engineers working with inherited pipelines, I'd bet that number is higher.

A few teams are starting to explore how to capture intent at the data layer, not just the code layer. The ones who figure out how to preserve decision context where data actually lives, at the edge, in pipelines, across distributed infrastructure, might be building something important. But right now, the tooling barely exists.
Why This Matters for AI Agents
Foundation Capital is right that agents need decision traces to exercise judgment. But consider what happens when we only capture traces at execution time.

An agent can follow a rule. It can look up a policy. But it can't understand why an exception was made last quarter unless someone captured the reasoning when it happened. It can see that a certain transformation was applied to a dataset but not why that approach was chosen over three alternatives that were discussed and rejected.

Research on AI decision-making keeps surfacing the same challenge: agents struggle with edge cases because they lack the contextual reasoning that humans use to navigate ambiguity. We've been trying to solve this with better prompts, more examples, refined guardrails. But the fundamental problem is upstream. The reasoning that would help agents handle edge cases was never captured in the first place.

Agents inherit our documentation debt. Every undocumented decision, every lost conversation, every piece of reasoning that exists only in someone's memory becomes a gap in the context graph. And agents can't exercise judgment across gaps.
The Compounding Problem
Context loss compounds in ways that aren't obvious until you're deep in a system you didn't build.

Every undocumented decision becomes a landmine for the next person (or agent) who encounters that code, that pipeline, that system. They see what was built but not why. So they either preserve it blindly (accumulating technical debt they don't understand) or change it without understanding the original constraints (breaking things the original author anticipated but never wrote down).

I've seen this pattern repeatedly. A team inherits a data pipeline with a seemingly arbitrary filter. They remove it because it doesn't match current requirements. Three months later, they discover it was preventing a subtle data quality issue that only surfaces under specific conditions. The original author knew about this. They even discussed it extensively with the team. But that conversation happened on a Zoom call that was never transcribed, and the person who made the decision left the company two years ago.

Multiply this across every team, every pipeline, every codebase. The DORA research shows that elite teams ship faster partly because they spend less time reverse-engineering past decisions. They've somehow preserved more context. Usually through heroic documentation efforts that don't scale.
The Path Forward
Foundation Capital's context graph thesis is right about the destination. Greg Ceccarelli and the SpecStory team are right about the first mile.

The platforms that win won't just capture decisions at execution time. They'll capture intent upstream, in the conversations, the debates, the reasoning that happens before anyone writes a line of code or builds a pipeline.

And they'll keep that intent close to where it matters. Versioned with the code. Traveling with the data. Available when someone (or something) needs to understand not just what happened, but why it was allowed to happen.

We're good at storing what happened. We're terrible at capturing why. The next trillion-dollar platforms will be the ones that figure out how to close that gap, not at execution time, but upstream, where the decisions actually get made.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

Originally published at Distributed Thoughts.

The $1B AI Drug Lab That Can't Touch Its Own Data

David Aronchick — Tue, 13 Jan 2026 06:12:34 +0000

Nvidia and Eli Lilly announced a $1 billion AI drug discovery lab today at the J.P. Morgan Healthcare Conference. The press releases are full of the expected language: "reinvent drug discovery," "accelerate medicine development," "foundation models for biology." Lilly's CEO David Ricks said they're "combining our volumes of data and scientific knowledge with Nvidia's computational power."

But, MAN, there is a phrase in there that is doing an INSANE amount of hard word: Combining our volumes of data.

How, exactly?
The Missing Paragraph
The coverage has something conspicuously absent: any discussion of how pharma data actually moves. The lab will be in South San Francisco. Lilly's clinical trial data, compound libraries, and patient information live in facilities scattered across Indiana, Ireland, and dozens of research sites worldwide. The announcement talks about "lab-in-the-loop" systems linking wet labs and dry labs in "24/7 AI-assisted experimentation."

That's a lovely vision. It also assumes data flows like water between these locations. In pharma, it doesn't.
Why Pharma Data Is Different
Clinical trial data contains protected health information under HIPAA. Proprietary compound structures represent billions in R&D investment and competitive advantage. Manufacturing process data falls under FDA's 21 CFR Part 11, which mandates complete audit trails for every electronic record: who touched it, when, why, and what changed.

These aren't bureaucratic inconveniences that clever engineering can route around. They're structural constraints that exist because the consequences of failure are measured in patient safety and billion-dollar regulatory actions.

I've been talking to teams that operate in these environments. The pattern is consistent: they don't lack compute. They lack the ability to make their data usable without making it movable.
The Air Gap Paradox
Traditional security thinking offers two options. Lock data down completely in air-gapped environments where nothing gets out. Or open it up for analysis and accept the exfiltration risk. Pharma has mostly chosen the first option, which is why so much valuable data sits in protected directories that researchers can barely access.

The promise of AI drug discovery assumes you can train models on this data. But training requires moving data to compute, or moving compute to data. The first option triggers every compliance alarm in the building. The second option is what the press releases hand-wave past.

Security teams need something in between: protected environments where data scientists can actually work, but where every attempted data movement gets logged, analyzed, and blocked if it violates policy. Not just access controls (who can log in) but egress controls (what can leave). The ability to process data, transform it, analyze it, without ever letting raw records escape the protected perimeter.

This is remarkably hard to build. It's also not a GPU problem.
The Audit Trail Problem
21 CFR Part 11 requires that regulated companies maintain computer-generated, time-stamped audit trails recording every modification to electronic records.

Let’s say that again. Every Modification

The trail must include the operator identity, date/time, and the nature of the change.

Now imagine training a foundation model on clinical trial data. The model sees millions of records. It learns patterns. It generates new molecular structures based on those patterns. What's the audit trail for that? When the model suggests a compound, which training records influenced that suggestion? When a researcher uses an AI-generated insight to make a decision, how do you document the provenance?

These aren't hypothetical concerns. The FDA released draft guidance on AI in drug development in January 2025, outlining a risk-based credibility assessment framework for AI models across nonclinical, clinical, and manufacturing phases. Regulators are actively figuring out how to apply existing frameworks to machine learning systems. Companies that can demonstrate clean data lineage from source through model to output will have a structural advantage in regulatory discussions.
What Nvidia's Billion Dollars Actually Buys
Nvidia and Lilly aren't naive about these challenges. The announcement mentions that researchers will "generate large-scale data" in the lab itself, creating new datasets specifically designed for AI training. That sidesteps some of the legacy data problems.

The collaboration will (likely) use Nvidia's BioNeMo platform, an open framework for building and training deep learning models for drug discovery that's been adopted by over 200 techbios and large pharma companies. They're also focusing initial efforts on applications where data constraints are less severe: manufacturing optimization, process simulation, early-stage compound screening. These are real opportunities where GPU compute genuinely is the bottleneck.

But the highest-value problems in drug discovery involve the data that's hardest to access: longitudinal patient records from clinical trials, real-world evidence from treatment outcomes, proprietary biological assay results accumulated over decades of R&D. That data can't just be copied to a shiny new lab in South San Francisco. And the estimated $1-3 billion cost to develop a single new drug happens largely because of failures that better data access might prevent.
The Actual Hard Problem
The companies that figure out "compute over data" for regulated industries will eat this market. Not by building bigger GPU clusters, but by solving the governance layer that lets valuable data become usable without becoming vulnerable.

What does that look like in practice? Tagging data at the source with cryptographic fingerprints so you can always verify provenance. Processing pipelines that run inside protected perimeters with whitelist-only egress. Audit systems that log not just access but every transformation, every query, every attempted export. The ability to prove, at any point, exactly what happened to every record.

This is boring infrastructure work. It doesn't make for exciting keynote demos. But it's the actual constraint on AI-driven drug discovery, and throwing more GPUs at it doesn't help.
What I'd Watch For
If you're evaluating pharma AI investments, look past the compute announcements. Ask instead:
How does the company handle data that can't leave its current location?What's their approach to federated learning or on-premises model training?How do they maintain audit trails through AI-assisted workflows?What's their story for regulatory submissions that involve AI-generated insights?
The GPU buildout is the visible part of the iceberg. The governance layer underneath is where the actual differentiation happens.

Nvidia's bet will work for some use cases. Public datasets, synthetic data, newly generated experimental results. But the highest-value pharma AI problems live behind walls that compute power alone can't scale. The billion dollars is impressive. The missing paragraph about data governance is the real story.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.*

Originally published at Distributed Thoughts.

Your 2026 Resolution: Add Context to Your Data (Before It Breaks You)

David Aronchick — Sun, 11 Jan 2026 06:11:42 +0000

Last week I sat in an executive review where two teams spent forty minutes arguing about "active users." Not about strategy. Not about growth. About what the number meant.

One team counted anyone who logged in. The other excluded users who bounced in under 30 seconds. Neither knew which experiment flags were active when the data was pulled. The dashboard just showed a number. No definition. No lineage. No context.

This happens constantly. And it's about to get significantly worse.

Gartner predicts that 60% of AI projects will be abandoned by 2026 because organizations lack "AI-ready data." Not because models failed. Not because compute was too expensive. Because the data traveling through these systems carries no meaning beyond the raw values.

The models can't tell the difference between a deprecated pricing page and current policy. They can't distinguish a test account from a real customer. They retrieve answers confidently, cite sources correctly, and still get everything wrong.

This is the year we stop treating context as optional documentation and start treating it as infrastructure.
The Context Engineering Pivot
Something shifted in 2025. The industry stopped talking about "prompt engineering" and started talking about "context engineering."

Andrej Karpathy called it "the delicate art and science of filling the context window with just the right information for each step." MIT Technology Review documented the transition from "vibe coding" to systematic context management. Google's December release of their Agent Development Kit was entirely focused on context architecture.

The terminology change matters. "Prompt" implies a single instruction you craft carefully. "Context" implies an entire information environment you engineer deliberately.

And it turns out most organizations have been engineering that environment with all the care of a teenager cleaning their room by shoving everything under the bed.

David Lanstein, CEO of Atolio, put it bluntly in IBM's 2026 predictions: "The solution isn't bigger models, but smarter data. True value will come from feeding models high-quality, permission-aware structured data to generate intelligent, relevant and trustworthy answers."

The race for bigger context windows missed the point. A 200K token context window filled with undifferentiated garbage produces undifferentiated garbage outputs, just with more confident citations.
What Context Actually Means
When I talk about context, I don't mean adding a few comments to your SQL. I mean four distinct layers that most data systems ignore entirely.

Semantic context is what a value actually represents. Not just "this column is called revenue" but "this is recognized revenue under ASC 606, calculated monthly, excluding deferred amounts, as defined by the finance team's Q3 2025 policy update." When the definition changes, the context changes with it. When someone queries the data six months from now, they see what it meant then, not what it means today.

Operational context is the health and provenance of the data at query time. Is this number fresh? Did the upstream pipeline fail overnight? Is there an active incident affecting the source system? A dashboard that shows revenue without showing "by the way, the payment processor had a three-hour outage last night" is lying by omission.

Experimental context is which flags and tests were active when the data was generated. Your MAU number is meaningless if you don't know that 40% of users were in an onboarding experiment that changed the activation flow. The number isn't wrong. It's just uninterpretable without the experiment metadata traveling alongside it.

Human context is ownership and decision history. Who defined this metric? What decisions have been made based on it? Where's the design doc? When someone has a question, they shouldn't have to play archeologist in Slack to figure out who to ask.

Most data systems capture maybe one of these. Usually the semantic layer, poorly, in a data catalog that nobody updates and fewer people read.
The Kubernetes Lesson I Should Have Learned Sooner
When I was the first product manager on Kubernetes at Google, we thought we'd solved the orchestration problem. Pods, services, deployments. State reconciliation. Declarative configuration. Ship your containers and let the scheduler figure out the rest.

What we hadn't solved was context.

A customer came to us wanting to run a global footprint of clusters, one per region, with synchronized jobs. Low-latency application, workloads coordinated across continents. We had an internal project called "Ubernetes" that was supposed to handle this, but the complexity was brutal. We ended up helping them build a custom solution.

The problem wasn't deploying the workloads. GitOps handles that fine now. The problem was that when data crossed cluster boundaries, all the context about that data evaporated. Each cluster was internally consistent. The global system was broken because nobody knew what the data meant in aggregate.

I've watched the same pattern repeat across every data problem I've worked on since. The compute orchestration is largely solved. The data orchestration is still a mess, and it's a mess because context doesn't travel with the data. This is actually why I'm writing a book on exactly this: the hidden complexity of data preparation that causes 80% of AI projects to fail.
Why RAG Doesn't Fix This
The popular assumption has been that Retrieval-Augmented Generation solves the context problem. Point your model at your documents, let it retrieve what it needs, problem solved.

InfoWorld's analysis last week explains why this breaks at scale: "RAG breaks at scale because organizations treat it like a feature of LLMs rather than a platform discipline. Models generate confidently incorrect answers because the retrieval layer returns ambiguous or outdated knowledge."

The failure mode is insidious. RAG with good retrieval but no context governance produces what I've started calling "hallucination with citations." The model cites a real document. The citation is accurate. The document is from 2023 and contradicts current policy. The answer is wrong, but it looks impeccably sourced.

CX Today reported on exactly this pattern: "If the knowledge base is outdated, RAG just retrieves the wrong answer faster. If content is unstructured, like PDFs, duplicate docs, or inconsistent schemas, the model struggles to pull reliable context."

The problem isn't retrieval. The problem is that the documents themselves carry no context about their validity, scope, or temporal bounds. A PDF is just a PDF. It doesn't know that it was superseded by a newer version, that it only applies to EMEA customers, or that the pricing section was invalidated by a board decision last quarter.

When VentureBeat declared "RAG is dead" in their 2026 predictions, they were being provocative. But the underlying point stands: RAG without context governance is dying. The organizations that will succeed with retrieval-augmented systems are the ones treating their knowledge bases as living, context-rich assets rather than static document dumps.
The Toll Booth Is Coming
There's a harder version of this problem emerging, and most organizations haven't noticed it yet.

Constellation Research warns that "enterprise data tolls and API economics are going to be a headache" in 2026. Celonis is suing SAP over data access. The Information reported that Salesforce is raising prices on apps that tap into its data. Connector fees are trickling down to IT budgets.

"Connection fees are going to be the new cloud egress," Constellation writes.

Here's what this means: if you don't own the context layer for your own data, you'll rent it from someone else. Every vendor building "AI-ready" connectors is essentially building a context layer on top of your data and charging you for access to the meaning of information you already own.

The Solutions Review predictions roundup makes this explicit: "By the end of 2026, connectivity, governance, and context provisioning for AI agents will be built into every serious data platform."

Built in. Not optional. Not a nice-to-have catalog project. Core infrastructure.

The organizations that treat context as someone else's problem will find themselves paying tolls to access the semantic meaning of their own customer data. The ones that invest now will own that layer.
Resolution #1: Ship Context With Every Event
The practical version of this starts at ingestion.

Every event entering your system should carry enough metadata that a reader (human or machine) can interpret it without external lookups. Not "user_id, timestamp, action" but "user_id, timestamp, action, schema_version, experiment_flags, source_system, data_classification."

This isn't aspirational. Anthropic's context engineering guide describes exactly this pattern: maintaining lightweight identifiers that allow systems to "dynamically load data into context at runtime using tools."

A transformation editor should show, live, which downstream dashboards and models will break if you drop a column. A query should surface its lineage alongside its results. A dashboard shouldn't just display a number; hovering over it should reveal the definition, the upstream tables, the freshness, and the last incident that affected it.

This requires tooling changes, yes. But mostly it requires treating context as a first-class output of every pipeline stage rather than an afterthought someone might add later.
Resolution #2: Make Context the Default in AI and Agents
TechCrunch's 2026 analysis identifies the Model Context Protocol as "quickly becoming the standard" for agent interoperability. OpenAI and Microsoft have embraced it. Google is standing up managed MCP servers.

The infrastructure for context-aware agents is arriving. The question is whether your data is ready to participate.

That means storing valid_from/valid_to timestamps on policy documents. It means tagging content with scope limitations (region, customer tier, product line). It means encoding data classification and retention rules at the source, not in a compliance spreadsheet nobody maintains.

Stanford HAI's predictions note that "2026 will hear more companies say that AI hasn't yet shown productivity increases." The organizations that do show productivity increases will be the ones whose agents can distinguish current reality from historical noise without human intervention.

An agent that refuses to take high-impact actions without verifying the environment, cohort, and guardrails is not cautious. It's correctly engineered. An agent that charges ahead on stale data with high confidence is the expensive kind of wrong.
Resolution #3: Measure Time to Trustworthy Insight
I wrote about Nicole Forsgren's new book last month. Her frameworks for developer productivity apply directly to data work, but with a crucial modification.

For data teams, the north star isn't deployment frequency or cycle time. It's time to trustworthy insight: from raw logs or events to a result you would put in front of an executive with confidence.

Most organizations can't measure this because they don't know when insight becomes trustworthy. The data arrives, transformations run, dashboards update, but confidence accrues informally. Someone senior enough eventually blesses the number based on vibes and experience.

Context infrastructure makes this measurable. If every metric carries its lineage, freshness, and incident history, you can ask: how long did it take from data landing to a metric with full provenance, no upstream incidents, and a defined owner? That's the number that matters.

When that number shrinks, you're actually improving. When people are just shipping dashboards faster without context, you're accumulating debt.
The Year We Stop Arguing About Definitions
Most New Year's resolutions fail by February. The gym membership lapses. The meditation app goes unused. The ambitious reading list gathers dust.

Data resolutions fail for the same reason: they're framed as one-time efforts rather than infrastructure changes. "We'll document our metrics" becomes a Q1 project that never gets maintained. "We'll improve data quality" becomes a dashboard that nobody checks.

Context isn't a project. It's a property of how data moves through your organization. It either travels with its story or it doesn't.

The organizations that treat 2026 as the year context becomes default will stop having the same arguments in every meeting. The exec review becomes a discussion of strategy instead of a debate about what "active users" means. The AI agent produces answers that come with their own credibility assessment. The data team ships products instead of debugging why downstream consumers don't trust the numbers.

Gartner says 60% of AI projects will fail for lack of AI-ready data. The projects that succeed will be the ones that stopped treating data as numbers and started treating it as knowledge.

That's the resolution. Make the data know what it is.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.

NOTE: I'm currently writing a book called "Zen and the Art of Data Maintenance" based on what I've seen about the real-world challenges of data preparation for machine learning, focusing on operational, compliance, and cost. I'd love to hear your thoughts!

Originally published at Distributed Thoughts.