DossierAtlas ReleaseProof

Release evidence you can inspect before you approve.

Comment

Inspiration

A green pipeline can belong to yesterday's source. A convincing AI review can repeat that mistake. DossierAtlas ReleaseProof asks a more useful question: does this evidence still belong to the exact work we are reviewing?

We built this standalone hackathon implementation from 22 October 2026 onward. Earlier DossierAtlas ideas inspired the problem; private legacy applications and the HMG corpus are not part of this public MIT submission.

What it does

ReleaseProof turns release evidence into a review that can be inspected and challenged. The browser workbench walks through Evidence → Reader → Challenger → Binding check → Next action. Ten synthetic scenarios explain matching evidence, changed source, incomplete coverage and contradictory assessments. These fixtures are explicitly labelled; the browser makes no model calls.

The Python workflow binds source, configuration, evidence inputs and run identity. The local runner executes checks, verifies recorded receipts and packages reviewable output. A changed source invalidates an earlier assessment. Even ACCEPT_FOR_REVIEW is a request for human review: release_authorized remains false.

The actual GitLab Duo integration is a custom Assisted flow, ReleaseProof Evidence Review (1019389, version 1.1.0). Its reader examines the supplied evidence; a native HumanInput checkpoint pauses before the challenger independently questions the reader; a second HumanInput checkpoint returns control to the human. The workflow exposes approve, modify and reject paths. Our bounded execution used Approve at both checkpoints and completed as session 10051270 on 26 October. We did not exercise Modify or Reject in that hosted session.

How we built it

The public implementation uses Python, browser JavaScript/HTML/CSS, GitLab CI and GitLab Duo Agent Platform. It keeps the original 22-file source alongside a maintained extension, 81 app files in total. MR !2 integrated the reviewed update. Public main commit b6f239028903249962c3c0527f08c63cccf49c1f passed pipeline 2989529338: original_source, maintained_source, maintained_workflow and browser_contracts, all four successful without allowed failure.

The native Duo flow was instructed to read nine public source files and four supplied public CI facts, using the existing hackathon service account. It read and challenged evidence; it did not deploy the application, independently fetch the pipeline or establish its checkout SHA. The source/CI identity was checked separately against GitLab. The one-shot Mention trigger is now off.

The submitted flow YAML is published at extensions/releaseproof/workflow/assisted-flow-candidate.yml. Its original candidate-only header predates the accepted version 1.1.0 and completed run; this dated account records the current state. The repository's older README and in-app Duo observation also preserve earlier execution states. Do not interpret historical session 10019740 as the new Assisted session.

A challenge that improved the result

The challenger corrected the reader: a fixture test checked statuses rather than exact negative findings, and JSON comparison was canonicalized rather than raw-byte equality. It also questioned whether an OBSERVED_PASS label could be mistaken for fresh process execution. Those findings are retained for triage instead of being converted into an unsupported all-clear.

Hash consistency is not authenticity. Synthetic fixtures are not hosted execution. Human approval of the next agent step is not release authorization. Keeping those distinctions visible is the product's core design decision.

What we are proud of

A working, inspectable chain connects local execution, a public four-job pipeline, real native Duo orchestration and two human decisions. The workbench makes the failure case understandable: one source change is enough to reject evidence that no longer belongs to it. The challenger can disagree with a plausible reader, and that disagreement survives into the handoff.

Try it

Clone the public repository. With Python 3.12+ and Node 24, run python3 -B extensions/releaseproof/ci/run_checks.py inventory and node --test extensions/releaseproof/tests/*.test.mjs. Serve the checkout with python3 -m http.server 8765 --bind 127.0.0.1 and open http://127.0.0.1:8765/extensions/releaseproof/dist/.

Use S03, Source changed after review, then inspect Reader, Challenger and Binding check. Select the matching-evidence scenario to compare its human-review outcome. The checked-in browser demo needs no credentials or paid model calls. The private Sites deployments are owner workspaces, not a promised public judge login. The public repository and video are the judging entrypoints.

Current public CI: https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/38101516/showcase/-/pipelines/2989529338

Native completed Duo session (GitLab access may be required): https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/38101516/showcase/-/automate/agent-sessions/10051270

What we learned and what comes next

The next useful improvement is stronger decision context: pass the first human decision explicitly to the challenger, add more exact assertions for negative findings, and improve the distinction between verifying a recorded receipt and observing a new process. These are follow-up goals, not claims of completed hosted behavior.

Appify/HMG integration is a separate experimental adapter. It is not a substitute for GitLab Duo, is not needed to run this submission, and contributes no private corpus or unverified inference claim to the entry. We have not established formal material-assurance, signed provider approval receipts or a remaining hackathon credit balance.

Path: Start Fresh. Autonomy: Assisted. Lifecycle emphasis: Verify, Package and Govern.

Built With

Share this project:

Updates

Submission history