Inspiration
A green pipeline does not tell a reviewer whether the file in front of them is the file that was tested. AI agents can produce changes faster than humans can inspect them. ReleaseWitness answers a narrower, verifiable question: which exact bytes passed which checks?
What it does
ReleaseWitness creates a release evidence passport binding a candidate artifact to its commit, build job, verification job and SHA-256 digest. A deterministic verifier blocks missing or inconsistent evidence. The interface exposes the reasons and GitLab source links. A local human acknowledgment is demo review state; it does not merge, approve or deploy in GitLab.
The live demonstration
We seeded an integer rounding defect in a toy quote service. Its real GitLab pipeline failed: 283 cents instead of 284. Our custom GitLab Duo flow, triggered by a manual mention, created a repair branch and MR changing only service/quote.mjs. It left tests, CI and policy unchanged and did not merge or deploy.
The repair pipeline passed all three jobs: unit tests, artifact build and packaged-service verification. We independently fetched the repair commit and ran all 29 tests successfully. The read-only collector then downloaded the actual pipeline evidence. The original artifact was ready for human review; appending one space produced ARTIFACT_MISMATCH; restoring the original bytes restored readiness.
Evidence:
One earlier session dropped before agent output. The retry completed. We retain that failure and do not claim measured reliability or time savings. Session access may require GitLab project permissions; the public MR and pipeline provide independently inspectable results.
How we built it
Dependency-free Node.js modules assemble a canonical manifest and artifact digests. A read-only GitLab REST collector uses a fixed HTTPS origin and rejects redirects. The verification job executes the packaged quote service, tying acceptance checks to the candidate bytes. Local fixtures also exercise stale commits, missing checks, failed verification and malicious log instructions; those fixtures are clearly separated from live evidence.
The custom Duo flow instructs the agent to modify only service/quote.mjs, reproduce the failure, run checks and propose an MR. Its prompt is a behavioral constraint, not an enforced sandbox. Deterministic evidence verification remains separate from the model's explanation.
Challenges and what we learned
Our first runner job appeared successful while its Duo session had failed. Later, the successful agent's prose incorrectly said no pipeline existed. We verified the session, diff and CI artifacts independently instead of trusting either a green runner status or generated prose.
A hash proves consistency, not an uncompromised runner or authentic source. ReleaseWitness does not establish production safety, replace code review or authorize deployment.
What's next
Repeat the bounded repair to measure reliability, and measure an identical manual baseline before making efficiency claims. Extend the evidence policy to additional artifact types without weakening the requirement to verify the exact candidate.
The 2:40 demo shows synthetic UI fixtures, a fresh collection of the real repair artifacts, and the historical October 22 Duo session, repair MR and passing pipeline. The historical repair is not presented as a new agent run.
Built With
- gitlab
- javascript
Log in or sign up for Devpost to join the conversation.