On Convergence

J. Brodnax and Claude (Opus 4.7, Anthropic)
Engineering Notes, Volume 1, Issue 2
April 2026

Contents

1. Durable Technologies
2. SQL, 1970
3. MVC, 1979
4. The Current Pain
5. The Convergence Point
6. Why chmod Wins Again
7. The Documents

1. Durable Technologies

The technologies that last fifty years are rarely the ones that were supposed to. Nobody writing the first relational model paper in 1970 believed they were specifying the database layer of the artificial intelligence era. Nobody sketching MVC on a whiteboard at Xerox PARC in 1979 believed they were drawing the architecture that would eventually underpin every web application, every mobile app, every desktop GUI, and every AI-driven user interface fifty years later. The authors of those ideas were, in their own accounts, solving the problems in front of them. That the solutions outlived the problems is a fact that only becomes visible in retrospect.

The industry has a persistent habit of announcing that one of these durable technologies is finally obsolete, usually in the first paragraph of a press release for something that intends to replace it. The replacements have names. Object databases were going to replace relational ones. XML was going to make SQL obsolete. NoSQL was going to make SQL obsolete again, in a different direction. Document stores. Graph databases. Key-value stores. Data lakes. Data lakehouses. Each of these technologies exists for a reason. Each of them solves a real problem. Not one of them has replaced the thing it was said to replace.

The question that gets asked less often is why. What is it about SQL, specifically, that has caused every attempt to replace it to end in the replacement becoming an adjunct rather than a successor? What is it about MVC, specifically, that has caused every framework designed to move beyond it to end up rediscovering the same three compartments under different names?

This essay is an argument that the durability of these technologies is not an accident. It is a property of the abstraction they chose. And that property is about to matter again, because the industry is in the middle of building another common protocol — the one that governs how AI systems produce, read, and transform data — and the question of whether that protocol will last fifty years or five is going to depend on whether we make the same choice the 1970s did, or a different one.

2. SQL, 1970

Edgar F. Codd's 1970 paper "A Relational Model of Data for Large Shared Data Banks" ran for eleven pages in the Communications of the ACM. It contained no code. It defined a handful of mathematical objects — relations, tuples, attributes — and a small set of operations on them. It proposed that every conceivable query a user might want to ask a database could be expressed as a composition of these operations.[1]

The paper was not popular at the time. IBM, which employed Codd, gave the project lukewarm institutional support at best; the company's existing products were hierarchical databases and the sales teams saw no reason to disrupt a working revenue stream. The first commercial implementation of the relational model did not come from IBM. It came from a small company called Relational Software, Inc., which later renamed itself Oracle.[2]

What made the model last was not its commercial reception. It was three properties of the abstraction itself:

First, the operations composed. Any two valid queries could be joined, filtered, projected, or aggregated into a third valid query, without restriction. This sounds obvious today. It was not obvious at the time. The prevailing hierarchical and network models required the developer to traverse pointer structures, and the structures did not compose — a query that worked on one schema typically broke on any structurally different schema.

Second, the operations were declarative. The user said what they wanted, not how to get it. The database was free to execute the query any way it liked, as long as the result was correct. This gave the implementation room to optimize, which turned out to matter more and more as data grew.

Third, the model was small. Codd's original paper specified five primitive operations (selection, projection, union, difference, Cartesian product) from which everything else was derived. A small core with generative power is the classical signature of a good abstraction, and it is the thing most replacements for SQL have gotten wrong. NoSQL offered many small cores, one per product, none of which composed with the others. Document stores offered a core so small it was essentially "here is a blob, good luck." Graph databases offered a model that was elegant for traversal and awkward for everything else.

The abstractions that last are the ones that compose. The ones that do not compose are always being replaced by the ones that do.

Fifty-five years after Codd wrote the paper, SQL runs approximately every mission-critical system in the developed world. Every fintech, every government, every logistics company. The banking system is SQL. The healthcare system is SQL. The airline reservation system is SQL underneath whatever web of microservices has been bolted on top. The replacements are all still around, and they serve real purposes, and not one of them has ever replaced the thing they were created to supersede.

3. MVC, 1979

Trygve Reenskaug was a visiting scientist at Xerox PARC in the summer of 1978 and 1979. He wrote a memo in December 1979 describing a pattern he had been developing for Smalltalk-80 to separate the presentation of a system from its logic.[3] The memo ran two pages. It named three compartments: a Model, a View, and a Controller.

The memo sat quietly for about a decade. It was revived in the late 1980s as Smalltalk's influence spread, picked up again in the mid-1990s as web frameworks needed a vocabulary for separating templates from business logic, and by 2005 or so had become the default architecture for web applications of every kind. Ruby on Rails, Django, Laravel, ASP.NET MVC, Spring MVC — the framework wars of the 2000s were fought almost entirely within the three-compartment model Reenskaug had sketched in a memo nobody read.

What made MVC last was the same property that made SQL last: the compartments composed. A Model could be swapped without changing the View. A View could be swapped without changing the Controller. A Controller could be swapped without changing the Model. The compartments had stable, documented contracts between them, and the contracts were small.

The 2010s introduced a wave of alternative architectures — Flux, Redux, component-scoped state, unidirectional data flow, MV-something-else. Each of them was a real improvement over some concrete MVC pain point. Not one of them replaced MVC. Open any React codebase today and you will find, in slightly different vocabulary, three compartments: data (a model), presentation (a view), and logic (a controller, usually now split across hooks and handlers). The names have changed. The pattern has not.

4. The Current Pain

Which brings us to the present. For the last eighteen months the software industry has been having a conversation about how to make its data "AI-consumable." The conversation has taken different forms in different subcommunities. Data infrastructure companies have been retrofitting vector indexes onto existing relational stores. SaaS companies have been publishing APIs with self-describing schemas intended to be machine-readable by language models. Analytics companies have been rebranding their dashboards as "AI-native." There is a persistent, low-grade sense that the existing data layer is not ready for the thing that is about to consume it.

Most of this anxiety is misplaced. An AI that can read a SQL schema can read a SQL schema. Codd's 1970 relational model is, if anything, more AI-consumable than any of the supposedly modern alternatives, because it is small, composable, and widely understood by the training corpus. No vector retrofit is required to make a SQL database comprehensible to a language model. The AI reads the table names, reads the column types, and generates the query. This works today. It has worked for years.

The actual pain is not in the data layer. It is in the emission layer. The AI can read the data fine. The AI can write queries fine. The question the industry has been slow to answer is: what happens when the AI writes back. When the language model generates a document, a row, a message, or a rendered fragment of markup, where does that emission go? Who signed off on it? What schema did it validate against? What audit trail does it leave? Who is allowed to see it? Who is allowed to undo it?

These questions are not new. They are the questions every enterprise system has had to answer for every human user since the first multi-user mainframe. What is new is that the industry is asking them in a context where the "user" is a language model that can generate a million emissions an hour, and where the consequence of an ungoverned emission is no longer a misplaced spreadsheet but a published document, a sent email, a shipped row of bad data, or an executed database mutation.

The Model Context Protocol, published by Anthropic in November 2024, is the standard answer to the first half of this problem: how an AI calls an application's tools.[4] MCP did for tool invocation what HTTP did for document transfer: it standardized the wire format so every participant knows what to expect. It did not specify the return path. It did not specify who signs what. It did not specify how the application governs what comes back out. These were deliberately out of scope for MCP, and correctly so — MCP is a tool-invocation protocol, not a governance protocol.

But someone has to specify the governance protocol.

5. The Convergence Point

The thesis of this essay is that the next common protocol in software — the one that governs AI emission the way SQL governs data and MVC governs presentation — is going to be a superset of the things we already have, written with the same conservatism that made the 1970 and 1979 originals last.

The protocol does not need to replace SQL. It needs to extend the vocabulary of CRUD operations with the verbs AI systems actually emit: transforms, elicitations, citations, diffs. It does not need to replace MVC. It needs to add a fourth compartment — the governance compartment — that sits between the Model and every outbound surface and gates what the application ships.

The emission protocol should be small. It should compose. It should be declarative where it can be, imperative only where it has to be. It should be five verbs, not fifty. It should specify exactly three surfaces through which AI-influenced data may enter the host system, not an open set. It should use an access control primitive that gates in constant time and composes without state — a bitset, not a role hierarchy.

StoneForge has been building this protocol for the last several months, under the name CRUD+. The name is deliberate: the intent is to extend an existing vocabulary, not to invent a new one. A language model that already understands Create, Read, Update, and Delete can absorb five more verbs in five minutes. A language model that has to learn an invented taxonomy invented by a single vendor has no incentive to invest.

The whitepaper and the RFC, both linked below, describe the protocol in detail. The core is small: a cell (an emission), a body (the persistent data the cell projects from), an envelope (a signed metadata shadow), five verbs (transform, elicit, execute, cite, diff), a chmod-style ACL bitset, and a Factory pipeline that gates every emission inline with its own production. No surface is allowed to ship an emission that has not traversed the Factory. No emission leaves without a signed envelope. No ungated path exists.

What makes this a durable design, if it turns out to be durable, is the same three properties that made SQL and MVC durable. The operations compose. The model is declarative. The core is small.

6. Why chmod Wins Again

The specific technical choice worth calling out is the access control primitive. CRUD+ uses a five-bit string modeled on Unix chmod: read, write, execute, deny-override, invoke. This is an aggressively old-fashioned choice. The modern SaaS industry spent the 2000s and 2010s building role-based access control (RBAC) systems of ascending complexity. Permissions became policies. Policies became policy hierarchies. Policy hierarchies became policy graphs. The tooling industry grew up around the complexity: every serious SaaS vendor now ships an admin UI for reasoning about who can do what to whom, and the UIs are, almost without exception, terrible.

chmod is five bits. It was specified in the original Unix filesystem design in the early 1970s.[5] It has survived every replacement. There are good reasons for this.

A bitset composes trivially. Given two bitsets, the combined grant is a bitwise AND (for "must satisfy both") or a bitwise OR (for "either is sufficient"). No state is required. No traversal is required. A gate decision is one assembly instruction on modern hardware.

A bitset inherits simply. A grant at the parent scope cascades down to the child scope by combining with whatever the child scope adds. An explicit deny at the child scope clears the corresponding bit. The cascade terminates in constant depth. No cycle detection is needed.

A bitset is legible. A five-character string — rwxdi — fits on one line of log output, one column of a database row, one row of an admin table. A user looking at a grant can read the grant. A policy system that takes a paragraph to explain one permission is a policy system whose users will not read it.

The AI era makes the case stronger. Modern applications have an unbounded number of emission surfaces — every face render, every command dispatch, every citation — and each of them needs a gate. A gate that costs one cycle to evaluate is fine at a thousand emissions a second. A gate that costs ten milliseconds of policy traversal is not. The scale of the problem has grown, and the primitive that scales is the old one, not the new ones.

This is the pattern. When the industry has a new problem, the best tool is often the old one, slightly extended. Codd solved the data problem in 1970; we are extending his model with vector operations, but we are not replacing it. Reenskaug solved the presentation problem in 1979; we are extending his model with a governance compartment, but we are not replacing it. Thompson and Ritchie solved the access control problem around the same time; we are extending their bitset with two additional bits, but we are not replacing it.

The industry's durable achievement is not invention. It is composition. The good ideas survive because they compose with the next good idea.

7. The Documents

The formal specification is published as RFC SF-004 in the IETF tradition: plain text, numbered sections, normative language, cited references. The narrative argument is the whitepaper, which is this essay's longer and more formal sibling. Both are free to read, free to cite, and free to implement. The reference implementation lives in the StoneForge repository under a permissive license.

If you are a protocol engineer, start with the RFC. If you are a technical leader evaluating the approach, start with the whitepaper. If you are here because you enjoyed this essay and want more of the narrative behind the decisions, the companion piece on the RFC genesis is linked as well.

The CRUD+ Release Set

The protocol specification, the whitepaper argument, and the reference implementation. All three documents are free to read, share, cite, and extend.

Read the Whitepaper RFC SF-004 Specification The RFC Essay Prior Whitepaper

The argument of this essay is that the durable software technologies are the ones that compose, that specify a small core, and that decline the invitation to reinvent what already works. The industry is about to decide what the common protocol for AI emission governance looks like. The decision is worth getting right, because the thing we decide now is the thing we will be living with in 2075, the same way Codd's 1970 paper is the thing we are living with today.

Write it down. Argue about it in public. Cite the predecessors. Keep the core small. The standard that lasts fifty years is the one that does those four things, and there is no shortcut.

J. Brodnax and Claude
April 2026

References

1. Codd, E. F., "A Relational Model of Data for Large Shared Data Banks," Communications of the ACM, 13(6), June 1970, pp. 377-387.
2. Stonebraker, M. and J. Hellerstein (eds.), Readings in Database Systems, 4th ed., MIT Press, 2005. The introductory chapter recounts the commercial history of the relational model and Oracle's early lead.
3. Reenskaug, T., "Models - Views - Controllers," Xerox PARC internal memo, December 10, 1979. The original two-page sketch is available at Reenskaug's personal site at the University of Oslo.
4. Anthropic, "Model Context Protocol Specification," November 2024. Available at https://modelcontextprotocol.io
5. Ritchie, D. M. and K. Thompson, "The UNIX Time-Sharing System," Communications of the ACM, 17(7), July 1974. The original specification of the Unix permission model. A refinement of earlier internal work at Bell Labs dating to 1969.
6. Brodnax, J., Ed., "CRUD+ Protocol: A Cell-Based Standard for Governed Data Emission in Agent-Native Systems," RFC SF-004, StoneForge Working Group, April 2026.
7. Fielding, R. T., "Architectural Styles and the Design of Network-based Software Architectures," Ph.D. dissertation, University of California, Irvine, 2000. The REST dissertation; cited here because it is the canonical example in the web era of a protocol that lasted by being small and composable.