← Back to blog

The Temperament Compromise in API Design

We have spent three centuries training our ears to accept a specific, measurable lie and to hear it as correct. It is one of the great engineering compromises, and it is almost exactly what you do every time you ship an interface.

Published July 2026 · 8 min read · API design / interfaces / music theory / systems


The major third you hear every time a pianist plays a C and an E together is wrong. Not mistuned the way a cheap instrument is wrong, but wrong on purpose, by about fourteen cents, sharp of the pure interval that physics would pick. Play a genuinely pure major third and a piano's major third one after the other and you can hear the piano's version shimmer and beat against the note beneath it. And yet every musician alive will call that piano in tune. We have spent three centuries training our ears to accept a specific, measurable lie and to hear it as correct.

The lie has a name, equal temperament, and it is one of the most successful engineering compromises in human history. It is also, almost exactly, the thing you do every time you design an API. Once you can hear the compromise in the music, you start hearing it in software, and it changes how you think about every interface you ship.

The principled lie

Equal temperament divides the octave into twelve identical steps. Each semitone is exactly one hundred cents, a frequency ratio of the twelfth root of two, roughly 1.05946, and every interval except the octave is deliberately bent away from its pure form. The tempered fifth sits at 700 cents against a pure 701.955, flat by about two cents, so close that almost no one notices. The tempered major third sits at 400 cents against a pure 386.31, sharp by nearly fourteen cents, the largest routine compromise in the system and the one your ear learned to forgive. The octave alone, a clean 2 to 1, survives untouched. Everything else is a small, principled wrongness.

The alternative is just intonation, and here is the thing worth getting straight before anything else: just intonation is not the primitive option we outgrew. It is the beautiful option we set aside. Just intervals are ratios of small whole numbers, the fifth as 3 to 2, the major third as 5 to 4, drawn straight from the harmonic series. An instrument tuned in pure ratios for one key is more consonant than any piano, genuinely and measurably purer, the chords locking together without a single beat. If you have only ever heard equal temperament, a well-tuned just-intonation chord in its home key can be a small shock. That is what we gave up.

An API specification is the same kind of object. A general-purpose interface is tuned to serve every caller adequately and no caller natively. It is a uniform, deliberate wrongness, accepted so that the interface stays playable in every key, which is to say every use case. The bespoke interface that would fit your particular problem perfectly, returning precisely the shape you need and nothing else, is just intonation: maximally consonant, exquisitely fitted, and quietly unusable the moment you change key. To see why we keep choosing the tempered version anyway, you have to look at the one thing just intonation cannot do.

Transposition is the whole argument

Just intonation is abandoned for exactly one reason, and it is not that it sounds bad. It is that it does not transpose. Tune a keyboard pure for C major and it is glorious in C major. Now play the same piece a fifth higher in G without retuning, and the ratios that were pure in C turn sour in G. Every modulation to a new key exposes a different set of intervals that were never tuned for it. The purity is real, but it is nailed to one key and cannot move. Equal temperament buys the opposite property: total harmonic freedom, the ability to play in any key, modulate anywhere, move a melody up or down at will, all for the flat price of never being perfectly pure anywhere. You give up perfection in one key to gain competence in all twelve.

That is the entire argument for the general-purpose API, transposed note for note. A bespoke interface, hand-fitted to one caller, is a just-intonation keyboard. It is gorgeous in its home key and useless in the piece that modulates. Its fidelity does not travel. Every new caller needs a new bespoke interface, and those interfaces do not compose, do not share tooling, do not share a mental model, and multiply until they collapse under their own maintenance. The value of a tempered API was never fidelity to any single caller. It is that the same interface, the same tooling, and the same mental model move across all of them. Transposition, reuse across contexts you did not anticipate, is the product. You are not paying the per-caller fidelity tax by accident. You are buying transposability with it.

You do not have to take the analogy from me, because the person who defined the dominant style of web API already stated it in these terms. In his 2000 dissertation introducing REST, Roy Fielding wrote that "a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs." Read that sentence with a musician's ear. A standardized form rather than one specific to needs is the precise definition of a temperament. Fielding even diagnoses the trade the way a tuner would, noting that REST is "optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction." Optimal for the common case, suboptimal for every specific one. That is a piano. The foundational document of modern API design is, read closely, an argument for equal temperament.

The bespoke end of the spectrum has a name too. The backend-for-frontend pattern, where you build a dedicated server tailored to exactly one client, is the just-intonation move: a purpose-built tuning for one key, wonderful for that client and inert for the next one, which needs its own. Each new frontend gets its own backend because the fit does not transpose. It is the honest choice when you truly have one caller. It is a trap when you forget that a second caller is coming.

The compromise you stop hearing

Fourteen cents is not subtle. It is roughly a seventh of a semitone, plainly audible when you put the pure and tempered thirds side by side, a slow beating you cannot un-hear once someone points it out. And still we call it in tune. That is the most important part of the whole story, and it is the part that should make an API designer nervous: the compromise did not merely get accepted. It became inaudible. It stopped being heard as a compromise and started being heard as reality itself, as simply what a major third is.

The same thing happens to a tempered interface, and it happens fast. A developer raised on REST comes to believe, without ever deciding to, that every domain really is a collection of resources you create, read, update, and delete. A developer raised on SQL comes to believe that every problem really is tables and rows and joins. The tempered shape of the interface becomes the perceived true shape of the domain. The temperament becomes your ear. And once it is your ear, you lose the ability to even imagine the interface that would fit the problem natively, because you can no longer hear that the tempered shape was ever a choice. You have forgotten there was a pure third. This is the quiet cost that no efficiency benchmark will show you, and it is more dangerous than any amount of over-fetching, because it operates on the designer rather than the design.

There is a second question hovering here, about what happens when you refuse to spread the error evenly and it piles up instead, catastrophically, into one unlucky key. That is a real and rich problem, and it is a different essay from this one. The point I want to hold onto is the one that comes before it: not where the error goes, but that you are tempering at all, and that the tempering disappears from view the moment it succeeds.

The middle paths, and why uniform usually wins

Music tried the compromises between pure and uniform, and software keeps rediscovering the same ones. Meantone tuning kept certain thirds pure by shoving the accumulated error into a few keys nobody was expected to play, which is the interface optimized for a handful of blessed callers while the rest quietly suffer, and it works right up until someone needs one of the bad keys. Well temperament, the world around Bach's Well-Tempered Clavier of 1722, made every key usable but distinct, each carrying its own color, which is a family of related interfaces, each slightly specialized, none perfect, all navigable, and it is the richest option and the most expensive to keep in tune.

Then there is a move music never had. You can retune on demand. GraphQL lets each caller ask for exactly the fields it wants, a fresh tuning computed per query, and it is genuinely closer to per-caller purity than a fixed set of endpoints. It exists because REST's uniform interface produces exactly the impurity the temperament analogy predicts: responses that carry too much for one screen and too little for another, the over-fetching and under-fetching that pushed Facebook to build and open-source GraphQL in 2015. But notice what the retuning costs. The uniform, cacheable simplicity that let REST transpose so cheaply is precisely what you trade away. You have not eliminated the compromise. You have moved it out of the interface and into your infrastructure, into query planning and caching and cost analysis. The error is conserved. You only get to choose where it lives.

Which is why, for interfaces meant to last, the industry keeps defaulting to the most uniform option it can get away with. The durable interfaces of computing, the narrow waists that everything else stacks onto, IP and HTTP and POSIX and SQL, are equal-tempered to the bone. They privilege no caller at all, they are slightly wrong for everyone, and that is exactly why everything can transpose onto them. The rule is the same one music arrived at by 1700: the more callers you must serve, and the more freely they must move between contexts you cannot predict, the more the uniform compromise outvalues the perfect fit.

What to do with a piano

So here is the practical residue, and it is mostly a change in the questions you ask.

Stop asking how to make the interface perfect for your most important caller. That instinct builds a just-intonation keyboard, beautiful and immovable, and you will pay for the purity the day a second caller arrives with a different key. Ask instead what the smallest uniform wrongness is that you can accept so that a caller you have not met yet is still playable without a retune. That question designs for transposition, which is the thing you are actually selling.

Know when just intonation is genuinely right, because sometimes it is. If you truly have one caller forever, one screen that will never be reused, one integration that will never spawn a sibling, then temper nothing. Build the bespoke interface and enjoy the pure third. Just be honest that you have done it, and hang a label on it: this is tuned for one key, and it does not transpose. The failure mode is never building a just-intonation interface. It is building one by accident and discovering, three callers later, that you cannot modulate.

And keep the native interface audible, which is the move that matters most and the one that is easiest to lose. The real danger of a good temperament is not the fourteen-cent error. It is forgetting the error is there. The mature engineer holds onto the knowledge that the resource, the table, the endpoint are tempered shapes, deliberate bends, conveniences chosen for their reach, and not the true and only shape of the domain. Hold onto that and you keep the ability to hear, when a caller genuinely needs the pure interval, that just intonation was always an option you could still reach for. Transposition is worth almost any price. Just do not let it cost you the memory that purity was ever possible. The finest tuners in history could always still hear the pure third they had chosen to bend. So should you.


Sources

The temperament becomes your ear. The discipline is keeping the ground truth audible under the convenient shape.

The essay's sharpest warning is not the fourteen-cent error; it is forgetting the error is there, letting the tempered shape read as the true one. That failure has a wider form in agent systems: the fluent, convenient output becomes the thing you trust, and the actual ground truth underneath it goes quiet. The agent trust stack is built to keep that ground truth audible — verification against what is actually true rather than against the shape that is easy to accept, a provenance record of what an agent actually did rather than what its interface implies, and ratings that price the work by its real track record. Ship the tempered interface. Just keep an instrument that can still hear the pure third.

Read the Theory of Agent Trust

pip install agent-trust-stack  ·  npm install agent-trust-stack

Or the provenance record on its own: pip install chain-of-consciousness / npm install chain-of-consciousness.