One live version at a time
A stable address points at exactly one published version. There is never a question of which agent is running, and going back is a matter of pointing the address elsewhere.
· 4 min read
IN SHORT
Each stable address on Czar points at exactly one published version at a time. The site's applications call the address, so there is never ambiguity about which agent handled a given run. When a new version is deployed the address moves to it; when a version is wrong the address is pointed back. The history of what was live is the history of where the address pointed.
A site that cannot say which version of an agent handled a run cannot really say what the agent did. On Czar this question never arises, because each stable address points at exactly one published version at a time. Whatever came through the address during a period was handled by the version the address pointed at then.
The rule
Deploying points a stable address at a version. The site's applications call the address. Exactly one version is live behind the address at any moment. When the operator deploys a new version, the address moves. When a version is wrong, the address is pointed back at an earlier one. At no point does the address point at two versions, split traffic between them, or overlap one with another.
This is a simpler rule than many deployment systems follow. It is chosen for what it makes possible.
Attribution and a readable history
Each run record names the version that handled it. Because only one version was live behind the address when the packet arrived, that name is unambiguous. A reviewer opening a finished run sees which version produced the draft, and can open that version to see the bounds and the steps it was operating under.
With two versions live at once, the same question would need a routing record to answer, and the answer would depend on which path a particular packet took. One live version makes attribution a matter of reading a date against a short list.
The deployment history for an address is a list: this version was live from this point, then that version, then the earlier version again. Each entry records who pointed the address and when. An auditor who asks what was live during a given week reads one line.
The history of bounds follows from this. Since the bounds are written into each version, and one version was live at a time, the question "what could the agent have done" has the same one-line answer. The article Bounds written into the version explains why the bounds travel with the version.
Rollback without reconstruction
When a version turns out to be wrong, the fix is to point the address back at an earlier published version. Published versions are frozen and kept. Pointing back does not rebuild anything or republish anything. The earlier version is exactly as it was when it was live before, and the applications calling the address do not notice a change in where it points.
This is only clean because there is one live version. If several versions shared the address, going back would mean deciding how to rebalance among them. With one, going back is moving one pointer. Pointing the address back at an earlier version describes the operational side.
Runs in progress
A run that began under one version finishes under that version. Its record names that version. New packets arriving after the address moves go to the new version. No run is handed across partway through, so no record contains steps from two different designs.
Operators who want a clean cut can turn the address off, let in-progress runs finish, deploy, and turn it back on. The article Turning a live address on and off covers that control.
What this rules out
One live version at a time means there is no gradual rollout behind a single address, no splitting a fraction of packets to a trial version, and no two designs competing for the same door. A site that wants to compare two designs deploys them at two addresses and has its applications call each deliberately. The comparison is then explicit, and each address still has one version behind it.
The platform accepts this constraint because the clarity it buys is worth more, for the kind of work agents do on Czar, than the flexibility it gives up. Desk work that sends, spends, or changes records needs to be attributable before it needs to be experimentally optimized.
The rule has a corollary. Drafts on the canvas are not versions, and an address cannot point at a draft. Work in progress is never live. Only a published, frozen version can sit behind an address, and only one of them does. The governance page describes how this fits with the rest of the platform's controls.
Questions this raises
- Can two versions of the same agent run side by side?
- Not behind one address. If a site wants to compare two designs, it can deploy them at two addresses and have applications call each deliberately. Behind a single address there is always exactly one live version.
- What happens to runs in progress when the address moves?
- A run that started under one version continues under that version to its end, and its record names that version. New packets arriving after the address moves go to the new version. No run is handed from one version to another partway through.
- Does pointing back to an earlier version require republishing it?
- No. Published versions are frozen and kept. Pointing back is a deployment act: the address is moved to the earlier version as it was. Nothing is rebuilt and nothing can come out differently.
KEEP READING