Essays • AI and engineering • • 15 min read

What the Deploy Believes About Itself

My deploy carries a model of itself in stamps, manifests and flags, and it was wrong twice in a month while the pipeline did the checking. Three loops, a crawl that had never passed, and the cybernetics underneath.

A vintage control console at night with one red indicator lamp lit, reflected in a dark window behind it, a notebook on the desk open to a hand-drawn loop

I pushed a new build of this site out one morning this week and watched the deploy script check its own work, which it does more carefully than I ever did by hand, comparing every file against what staging had been serving, going page by page through the site to explain each change, reading the security policy at the edge, and then printing Done with a rocket, and I believed it.

An hour or so later the crawl that runs behind every production deploy came back red on sixty pages, all of them old addresses that are supposed to redirect, and when I looked back it had been saying the same thing on every run since the day I wrote it. The site was fine. The pipeline had an idea about what a page is, I had given it that idea, and nothing but the pipeline was ever going to check it.

What the deploy checked that morning Result
files in the artifact compared with the staging bucket 6,203, none different
pages fingerprinted, every change explained 598, by six source files
scripts in the build allowed by the live security policy all of them
redirects verified at the edge 80 of 80
pages the background crawl expected to answer 200 60 answered 301
production runs of that crawl, ever 28, all red, the same 60 each time

What I asked ChatGPT

That same evening I was a long way into a conversation with ChatGPT that had started somewhere else entirely, with eigenvalues and the cycles I track by the stars, and had wandered into whether a thing can carry around a description of itself. Somewhere in there I typed the question the way it came out, "Do systems carry within the language to describe there implementation models", and left the spelling.

The answer drew a line I had not drawn for myself. A crystal embodies its rules and describes nothing. A thermostat has a rule but no model of the furnace, and a controller built around a model is the first thing in that line that can be wrong about itself, which is what an adaptive one is for. I asked how any of that applies to DevOps and the reply was that a release pipeline already carries partial descriptions of itself, in the YAML and the manifests and the Terraform, and those describe what was intended. Telemetry describes what happened, and the work is to connect the two and keep testing whether the descriptions are still true.

I sat with that for a minute, because I had spent October building exactly that for this site without having the name for it. And the question itself was not new to me either. Two weeks before, outside in the late October sun, I had written this in the notebook:

There are traces left even if we cannot yet see or decode the messages. Like the story of our planet embedded in the crystals it produces, our own story is embedded and encoded and it may be a one way process to get at that directly once observed that itself changes how it works and may be a part of the system itself as a protection of sorts.

The crystal was already on the page. So was the catch, that reading the description changes the thing described, which is what the rest of this post is about.

What a release believes

Here is what my deploy believes about itself, where each belief gets its evidence, how it is tested, and whether it has turned out to be right. Rest on a row to follow it across.

What a release believes about itself, how each belief is tested, and where the evidence comes from Six beliefs this site's deploy holds about a release, each with the test that checks it and the evidence the world supplies. Three have been right so far, two were wrong, one has never been tested on production. Under the columns, three return arrows: a failed test can correct the release (loop one), correct the belief (loop two), or change how the test gathers its evidence (loop three). What the deploy believes How it is tested What the world supplies the bytes going live are the bytes staging served, that I looked at the artifact staging saved, the staging bucket every file hashed and compared before anything is uploaded right so far every changed page is explained by a source edit, a listing, or site code the pages the live site serves right now each page's text fingerprinted, compared with the last manifest right so far the edge serves this build the edge, a minute after the cache was cleared stamp, sampled bytes and policy fetched after the invalidation right so far the artifact came from a clean tree one flag, sampled from git (after the build, for six days) the promote refuses a dirty flag wrong the pages to crawl are the site's pages the manifest and the sitemap, redirect pages included every one fetched, expected to answer 200 wrong the last release can be put back object versions in the bucket a rollback, run once, on staging never tested When a test fails, the red light can send you three different places Loop one, regulate act on the release: stop the deploy, roll it back Loop two, correct the belief the world moved on; update what the deploy believes, then ship Loop three, change the test the evidence was gathered wrong; change when or how it is read

Six things the deploy believes about a release, the test that checks each one, and what the world supplies. Three return arrows underneath: the same red light can correct the release, the belief, or the test itself. Drawn from the deploy's own record.

The same six, as a table.

The deploy believes Where the evidence comes from How it is tested Has it been right?
the bytes going to production are the bytes staging served and I looked at the artifact staging saved, the staging bucket every file hashed and compared before upload yes so far; once it caught a mismatch and refused
every page whose text changes is explained by a source edit, a listing, or site code a fingerprint of each page's readable text, the manifest the last deploy shipped compared page by page before anything is uploaded yes so far; an unexplained page stops the deploy
the edge serves this build the build stamp, a sample of objects, the live security policy fetched after the invalidation and compared byte for byte yes so far
the artifact came from a clean tree one flag sampled from git the promote refuses a dirty artifact no, wrong for six days
the pages to crawl are the site's pages the manifest and the sitemap every one fetched and expected to answer 200 no, wrong since the day the crawl was written
the last release can be put back object versions in the bucket exercised on staging, once never tested on production

What the conversation pushed me toward is the right-hand column, because a thing written into a pipeline is not true for having been written there, it was true on some day on some evidence, and the day and the evidence are what I had never kept.

Three loops

ChatGPT laid it out as three loops doing three different jobs, and I recognized all three on this site.

The first loop is the one every pipeline already has. A page fails the canary and the deploy stops, the way the furnace comes on when the room gets cold. This is the thermostat, and it is the one piece of cybernetics that ever reached working engineers.

The second loop corrects the model, and I watched it work the day before the promote, when a documentation commit landed while staging was still building. The staging bucket ended up stamped with one commit and the artifact with another. When I went to promote, the script refused, and the refusal named both commits, the one staging was serving and the one in the artifact.

The pipeline's belief about what staging was serving had gone stale by one commit, and instead of shipping on the belief it said so. Nothing needed rolling back, the model needed updating, and it was, by deploying staging again from the settled commit.

The third loop works on how the model gathers its evidence, and this is the one I want to tell properly, because it has now happened to me twice.

In October I wrote about checks that could not fail, and one of them was the build stamp, the little flag that says whether a build came from uncommitted work. It said dirty every time, because the content cache wrote the clock into itself. I fixed it. Three weeks later the flag was on again, on every build, for a different reason. The staging script read the flag after the build, and the build rewrites a tracked file, so the sample was measuring the build's own side effects. By then the flag had become a term in the promotion contract. Production refused every artifact as dirty, fell back to a full rebuild each time, and passed every budget while doing it. Build after build was stamped dirty, promote after promote was refused, and nothing in the record read as a pattern because each refusal pointed back at staging and looked like a one-off.

The dirty flag October November
what it said dirty, every build dirty, every build
why the cache wrote the clock into itself sampled after a build that rewrites a tracked file
what trusted it nobody; I had stopped looking the promotion contract
cost a light nobody read six days with no promotion path; two confusing failures
the fix the cache dates itself from git the sample moves before the build, in both scripts, and a test forbids any other sample

The fix in November was not a value, it was a change to when the evidence gets gathered, in both scripts, with a test so neither can gather it later again. A loop working on how the other loops see. Since then the promotion path exists again, and the refusals that remain are the contract saying no to real drift, or me tripping my own preflight.

Production runs since the fix
promoted staging's bytes, green 4
rebuilt and shipped, green 2
stopped before upload by a check or the contract 5
failed after upload, on the edge check 1

I know this one from the page, too. Last December a pen developed an edge and I spent a page blaming the pen, "like a bad limp after some time the weakness begins to affect the whole", and when I took it apart there was no ink left in it. The reading was right and the thing I believed about the instrument was wrong, and nothing on the page could have told me which.

Where the cybernetics comes in

Heinz von Foerster drew the line, in the short paper I read last week, between the cybernetics of observed systems, which is first order, and the cybernetics of observing systems, which is second. The first two loops watch the release. The third loop watches how the pipeline watches, and changes it. I had the question in my own words before I had his, on a December page, "Who is the director of the director?"

There is an older line underneath, from Roger Conant and Ross Ashby, and it is the title of their paper. Every good regulator of a system must be a model of that system. I have been quoting that title since before I started the reading, and the deploy taught me its shadow the hard way. A regulator with a wrong model does not stop regulating, it regulates confidently in the wrong direction, and for six days mine refused good artifacts and rebuilt them while every number it reported was green.

The sixty redirects are the same thing at a smaller size. The crawl believes the manifest lists pages. The manifest also lists the little files the builder writes for each redirect, and at the edge those answer with a redirect, by design. The belief was off by one definition of the word page, and that was enough to turn the check red on every run. I fixed the belief rather than the pages while this post was open, so the crawl now reads each address from the build first, expects a redirect page to redirect, and follows it to where it lands, and the next run was the first green one it has ever had. I wrote in October that a light that is always on is not a light, and the same goes for one that is always red.

The crawl Before After
runs 28 1
result red every time, the same 60 addresses green
what it expected of a redirect page a 200 a redirect, followed to a 200
pages fetched, redirect pages followed 598, none 515, 83
time about four and a half minutes under two

The two tanks

Late in the conversation I asked whether universal self-referential eigenvectors were good for anything. The answer was better than my question. It wrote down a two by two matrix that could be read as a system coupled to a model of itself, found the mode where state and model move together and the mode where their disagreement decays, and then showed that the very same matrix describes two tanks of water exchanging a fifth of their difference each step, with the same eigenvalues and the same eigenvectors and no model anywhere in it. The arithmetic cannot tell you whether a variable is a model. What can is an intervention, changing the model while holding the world still and seeing whether the behavior follows.

That is the deploy question again in a different coat. The way to know whether a belief in the pipeline is doing anything is to make it false on purpose and watch for the refusal. I asked that of my checks in October. Can it fail. The conversation gave me the reason it is the right question.

The questions I am left with

I am leaving this as questions, because the questions are the part that carries over to any pipeline, and the answers are particular to each one.

What does the pipeline believe about the release, written somewhere a person can read it? Where does each belief get its evidence, and is that evidence gathered before the thing it measures or after? Which beliefs have ever been contradicted, and which have never once been tested, which is a different silence from never having failed? And for any one of them, can I make it false on purpose and watch the pipeline refuse?

A pipeline with answers to those has a model of itself. One without them has a thermostat and a dashboard, which is fine until the model is wrong, because then the pipeline is wrong with full confidence and every light stays green.

Von Foerster ended his paper on responsibility, that if we do not name our own purpose somebody will name it for us, and the pipeline version of that is smaller and the same. If nobody writes down what the release believes, the release believes whatever the scripts happen to measure, and nobody is watching the watching. Cybernetics is the steersman's word, and on a February page I wrote, build the rudder. The pipeline is a rudder. What it believes about the water is the chart, and the chart is the part I had never once checked.

This post is in the loop

Whatever this is, it is not only a post about a pipeline. The crawl got fixed because writing this down made the red run impossible to leave alone, so the essay did the third loop before it had finished describing it. The voice check I run on every draft said the opening sounded like me and I read it and it did not, which is the same shape again, an instrument reading true about everything except itself, and that went into the notes the next draft starts from. And the October page had already said it, a few lines above the crystal, "Recursive systems leading back to breath itself and the one loop seemingly running it all." I did not plan a retrospective and this became one on the fly, which is how a loop closes when it is left to run, and the shape is the same at every scale I look, a planet in a system in a galaxy, a deploy in a blog in a life, the thing that watches sitting inside the thing it watches. Observe the observer. Place the system itself onto the system.

Where this sits

If you want Go to
the checks that could not fail, and the questions I now ask of one Every Check Passed
the gates in the studio, and the number that measured the thing next door The Gates Are the Product
a loop made wrong on purpose and measured, with Ashby's law The Regulator Was Fed Intents
why a loop is the special case of a path A Loop Is a Path That Closes
first order and second order, in von Foerster's own short paper Anything Said Is Said by an Observer
the hubs this hangs from AI development and Complexity and systems
the reading path Cybernetics
the notebook pages quoted here, as written Observe the Observer, Raw Thoughts of a Biological LLM, Build the Rudder

Sources

Source What it supports
A conversation with ChatGPT, November 2026 the crystal, thermostat and controller line; the three loops; the release that carries its beliefs with evidence and a status; the two-tank counterexample
Roger Conant and W. Ross Ashby, "Every Good Regulator of a System Must Be a Model of That System", International Journal of Systems Science, 1970 (PDF) the title, which is all I lean on
Heinz von Foerster, "Cybernetics of Cybernetics" (1979), reprinted in Understanding Understanding (Springer, 2003) observed systems and observing systems
this site's deploy scripts, their metrics file, and my write-up of the dirty-flag incident every number in the tables