Seven questions a deploy pipeline answers for you
Separate environments, automated tests, a green build, a person reading the diff, then promotion to production. That sequence encodes about thirty years of outages. Anyone selling you a way around it deserves suspicion.
So the useful question for agent tooling is a narrow one. What is the pipeline actually checking, and where else could each of those checks live?
The seven questions
Strip a mature CI/CD setup down and it answers seven things on your behalf:
- Does it build? Compile, lint, type-check. Malformed code never reaches a runtime.
- Is it what the author meant? A person reads the diff, and the bytes that ship are the bytes that were written.
- Is the world still as the author assumed? Merge base, conflict detection, dependency locks.
- Has it already run? Deploy idempotency, so a retried job ships once.
- Does it behave? Unit, integration and smoke tests, against something that isn't production.
- Can it be undone? Version history, tagged releases, a rollback that's one command.
- Who did it? Attribution on the change, durable enough to audit a year later.
Those seven survive any change of substrate. dev → staging → prod is one implementation of them, refined over decades, and a very good one. Confusing an implementation with the principle is how teams end up with three environments and no answer to question 6.
Why you would move a check at all
CI verifies once, at build time, against a snapshot of the world. Your tests ran against the merge base as it stood twenty minutes ago. In the interval, main moved, a dependency published, a config changed, someone else's release landed. The artifact stays valid. The assumptions underneath it may have expired.
Blue-green deploys and canaries limit the damage. The window stays open, because the check and the write happen at different moments by design.
Once the unit of change is a single addressable write, questions 2, 3 and 4 can move onto the write itself, as preconditions the server evaluates at the moment it commits.
This is old news, which is the point
If that sounds like If-Match and ETags, or compare-and-swap, or an idempotency key on a payments API, it should. HTTP settled question 3 in 1999. Distributed systems settled question 4 well before that. None of this is a new idea and we won't pretend otherwise.
The odd part is that deploy pipelines mostly answer those questions with a place instead. A branch, an environment, a queue. For a batch of changes arriving together that's the practical tool. When the unit of change shrinks to one write, the older answer fits better.
HTTP settled question 3 in 1999. A deploy pipeline still answers it with a branch.
Our own table, with the verb on every row
Here's where each of the seven lands on OBTO today. The verb matters more than the description, so it gets its own column. Two rows say partial, and we wrote about what production actually requires before we were finished supplying all of it.
| Question | Where it runs | Verb |
|---|---|---|
| 1. Does it build? | An artifact deployed whole is parsed before it persists, and a malformed module is rejected instead of stored. A line-level edit is not re-parsed. | Refuses |
| 2. Is it what the author meant? | A staged upload can carry the hash the caller expects, and the commit is refused on mismatch. Supplying the hash is the caller's call. Nothing here reads the diff. | Checks |
| 3. Is the world still as assumed? | An edit can carry the line it saw and a hash of the file it saw. Both are optional arguments, so they protect the callers who pass them. | Checks |
| 4. Has it already run? | A key naming the write replays a stored receipt instead of executing twice. If that receipt store can't be read, the call refuses instead of guessing. | Checks |
| 5. Does it behave? | Validation, route invocation and headless preview are tools the caller runs. Diagnostics, with no server-side consequence for skipping them. | We recommend |
| 6. Can it be undone? | A write returns the bytes it replaced, in the same response. There's no version store, no tagged releases and no one-command rollback on the API. Our own agent keeps restore points; the API doesn't expose them. | Partial |
| 7. Who did it? | Activity is itemized per run. Attribution carried on the record itself is thinner than this row deserves, and finishing that is on the roadmap. | Partial |
The two rows we'd defend hardest
Row 1 has no opt-out. There's no argument that disables it and no flag that skips it, which is what separates it from rows 2 through 4. A check that depends on the caller behaving well is a good check. A check that doesn't is a different category, and on a platform where the caller is a language model that distinction does real work.
The write tells you whether it's serving yet. Server-side code returns a success meaning durably stored, with running processes still on the previous version until they cycle, and a two-replica cluster split between old and new until then. A deploy job reports success when the job finishes; in a batch pipeline the deploy is the propagation, so there's nothing to distinguish. Telling the caller that its successful write isn't live yet matters most when the caller is an agent about to verify its own work.
Where this is weaker
Integrity is a different property from correctness. Hashes and anchors catch corrupted bytes and stale assumptions. A well-formed change that is simply wrong sails through all of them. That's question 5, and it belongs to tests and to a person who cares. We've said this before and it hasn't stopped being true.
There's no staging tier. No separate environment, no promotion path. If your change must be exercised somewhere that isn't live before it ships, that's a genuine gap today, and it's the first question a careful buyer asks.
Rows 6 and 7 say partial. Question 6 gets you the bytes a write replaced and stops there. Question 7 gets you a per-run record and less on the artifact itself than an auditor would want. Both are being worked on, and neither is done.
How to audit any vendor, including us
Take the seven in order. Ask what happens when each answer is wrong, then ask for the verb. Sort every claim into three buckets: the server refuses the write, the tool offers a check the caller can skip, or it's a line in the documentation. Those describe three different systems, and a feature grid will show you one column.
The table above has two partial rows and a checks where we'd have preferred refuses. Any vendor can publish the same thing. The getting-started guide covers a first deploy on the free Builder tier, and the pricing page lists the tiers and the metered rates.