Receipt is truth: what comfort-ci is trying to prove
A field note on continuous integration, durable deployment evidence, and why a green check is not the same thing as proof that the intended software is actually running.
A green check is a shadow
Most continuous-integration systems are very good at telling you that a sequence of commands completed. That is useful, but it is not the same claim as saying the intended source became the artifact now serving users.
comfort-ci is built around that distinction. A GitHub Check is a convenient projection of the run. The durable receipt is the stronger record: repository, source commit, artifact identity and post-deploy verification belong together. If those facts do not agree, success should not be inferred from a green interface.
The deployment has to answer for itself
The interesting failure is not always a failed build. It is a deployment that appears successful while the evidence chain is incomplete: stale workspace state, a superseded commit, an inherited dependency tree, or a live service that does not correspond to the artifact we thought we promoted.
That changes the question from ‘did CI pass?’ to ‘what exactly is running, where did it come from, and what durable evidence connects the two?’ The latter is harder to fake accidentally.
Adversarial by design
The current work deliberately attacks the trust boundaries instead of merely adding features. Warm workspaces are treated as contaminated until reset to the admitted source. Duplicate and out-of-order signals have to preserve ordering. Heartbeats cannot become proof of useful work. A deployment cannot outrun the evidence that identifies it.
The point is not to make failure impossible. It is to make failure legible. When a system cannot prove an invariant, the honest state is unknown or failed—not a cosmetically successful check.
Why publish the prototype
comfort-ci is published as software because the architectural claim is more useful when there is a citable artifact behind it. Version rv02 is archived on Zenodo under DOI 10.5281/zenodo.22000632, with the concept DOI 10.5281/zenodo.21938461 representing the version line.
The publication is not a claim that the system is finished. The record itself says ‘Working Prototype kept working.’ That is the useful boundary: preserve what existed, make the lineage inspectable, and keep development status separate from retrospective proof.
The larger pattern
This is one instance of a broader Comfort Curators rule: external success should not outrun durable evidence. The same discipline matters anywhere software acts across infrastructure, data, agents or operational systems.
A receipt is deliberately boring. That is its strength. It gives a fluent system, an operator and a future auditor the same object to argue with.