GitLab Duo repairs the code. MathGraph checks whether the exact revision, completed CI evidence and deployed files justify handing the release decision to a human—and refuses readiness when the evidence is insufficient.
Finish the workflow, with evidence that stays current
After an AI agent repairs code, developers still have to reconcile the merge request's source revision, CI results, deployed files and release decision. A successful command alone does not establish that the current candidate is ready, that its exact files reached the live site, or that its supporting evidence is still valid.
MathGraph — The Warranted Release Agent brings those questions into a supervised GitLab workflow. It combines a working Go YAML parser, an interactive release cockpit, independently checked native evidence and a custom GitLab Duo flow. The developer gets an inspectable outcome linked to the exact candidate, pipeline and artifact manifest.
Duo makes the change. MathGraph checks what the evidence supports. The developer controls production permission.
New: a final answer after CI finishes
The recorded repair demo originally left an honest UNKNOWN comment while CI was pending. We have now completed that reporting handoff in MR !4:
- While required automatic work runs, progress stays in report artifacts. Observed failures remain explicit; an unfinished run is not presented as a completed outcome.
- After all nine required automatic job outcomes settle, the helper rechecks the MR head and pipeline, then posts one final READY_FOR_HUMAN_REVIEW, BLOCKED or UNKNOWN report for that exact candidate and pipeline.
- Ready requires completed checks, current native support and deployed-byte identity. The observer compares the public manifest with the manifest retained by CI, then hashes all eight deployed payloads in full, including the real Go WebAssembly parser and native evidence.
- An identical final retry returns UNCHANGED without another comment. Historical reports remain intact. The flow uses its existing Developer-level access; it does not need permission to edit earlier bot comments.
This is demonstrated in session 9989631, on candidate 1cedd7ac9060c8113d0ff9904a3fe0593ef80ed0. Pipeline 2983038019 passed all 10 automatic jobs: nine required checks plus the completion-report job, including 119 Python tests. All four declared native obligations were WARRANTED, and all eight deployed payloads matched the retained manifest: 6,878,891 bytes.
The bot created one final report. The following helper invocation reported UNCHANGED; independent readback confirmed the same body and timestamp, with all seven historical reports preserved. This run verifies the completed handoff; the separate recorded MR !3 run below demonstrates the repair itself.
The overall pipeline remains manual/Blocked because its separate production-authority demonstration is intentionally unrun. Public staging and final reporting have completed. The report covers declared native contracts and one observed deployed-byte snapshot; production permission remains a human decision.
Recorded demonstration: a real Duo repair
Our private MathGraph Warranted Release flow runs only when explicitly mentioned. It has an investigation/repair component and a separate reporting component, using GitLab Duo Agent Platform with a Developer service account and the triggering user's composite identity.
The controlled demonstration is retained in MR !3:
- We deliberately introduce a wrapper defect on an isolated branch. It discards the parsed value; this is an injected experiment, not a naturally discovered upstream vulnerability.
- Pipeline 2974715543 fails its existing quoted-scalar and string-roundtrip contracts at
5f1dca6c. - One explicit mention starts custom flow session 9862638. It reads the MR and workflow, reproduces the failure, removes the injected line, commits and pushes only the source branch, and qualifies the clean committed candidate.
- The reporting component rechecks the MR head and posts UNKNOWN while CI is pending, keeping an agent's opinion distinct from checked evidence.
- Pipeline 2974721048 subsequently passes all nine configured automatic jobs, plus the generated Pages deployment. The retained decision binds four WARRANTED native obligations to
abefa2d82d349bf1971a318d0af75ef01265fede; production approval is false.
Independent diff review confirms that the repair removed exactly one injected application line. Tests, CI, policy, verifiers, resolver and upstream source were unchanged. Sandbox setup failures and the initial failed pipeline are preserved. The demo MR remains a draft; the production-authority job stays manual and unrun.
A product you can inspect
Open the live app. The cockpit connects release status to its exact source and pipeline. Inspect dependency details, filter obligations, open raw evidence, and try the Parser Lab. The browser runs the real imported Go YAML implementation compiled to WebAssembly; it is not a JavaScript parser simulation.
Four finite native obligations cover quoted scalars, string roundtrips, service health and native packaging. A separate Python checker validates native test events, process exits, required test identities, and source/contract/verifier digests. A Go resolver computes the dependency-aware decision:
- WARRANTED: required support is checked and current within the declared boundary.
- BLOCKED: a required obligation has an observed failure.
- UNKNOWN: support is missing, inconsistent, stale or withdrawn.
Production permission is separate. Its manual gate requires both the exact candidate SHA and the digest of the exact artifact manifest, rechecks payload coverage and bytes, then rechecks native evidence. There is no production deployment adapter.
What happens when evidence loses authority?
Run history exposes actual CI snapshots from a reproducible A/B/C experiment. A qualifies the good candidate. B injects the wrapper defect: health remains green while semantic requirements fail. C withdraws YAML authority: the dependent release becomes UNKNOWN, while unrelated roundtrip, health and package support remain WARRANTED. Clearing withdrawal alone cannot revive stale receipts; fresh affected qualification restores support. Selecting a recorded case does not change the deployed candidate.
An equally informed conventional baseline catches the injected defect too: this is a correctness tie. The contribution is explicit dependencies, selective revocation, freshness and candidate/artifact-bound human permission—not a claim that normal tests cannot find the bug.
How we built it with GitLab
Earlier Duo sessions authored the initial resolver/checker and integrated reviewed implementation; their failures and corrections remain visible in MR !1. MR !2 adds the cockpit, real A/B/C publication, payload inventory and artifact-bound gate. The custom flow in MR !3 demonstrates operational repair, qualification and reporting. MR !4 subsequently adds the verified final-only handoff and complete deployed-payload comparison. Human direction and independent checks supervise the outcome; we do not claim autonomous authorship of all implementation.
The current MR !4 pipeline executes native and upstream tests, 119 Python tests, source provenance, go vet and module integrity, qualification, packaging, runner-local staging smoke, Go WASM and cockpit controls, Pages deployment and one public post-deployment observation. The repository retains replay instructions, raw evidence and negative candidates.
Path B: new work around an existing MIT project
Original project: https://github.com/goccy/go-yaml — exact imported commit a34b94ecb553bb5a693296c30232a89026db79ca. Its original source and MIT notice are preserved. The wrapper, browser product, contracts, checker, resolver, controls, custom flow and deployment were created during the submission period, on or after October 5, 2026. We do not present the upstream parser as our work. New work is MIT licensed.
Public source and instructions: https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/14393368/showcase
Live app: https://showcase-ae0c0b.gitlab.io/
Watch the updated 2:59 MathGraph demonstration: https://youtu.be/1NgpOCCalIs
The recorded demonstration presents the release cockpit, selective evidence withdrawal, and the custom GitLab Duo repair workflow in MR !3. It shows the agent investigating and repairing an injected defect while MathGraph reports an honest UNKNOWN until the required CI evidence becomes available.
The updated video also introduces the completed MR !4 release-verification handoff: 10/10 automatic jobs passed, including 119 Python tests; four native obligations were WARRANTED within their declared scope; and all eight deployed payloads matched the retained artifact manifest. The MathGraph bot published a final READY_FOR_HUMAN_REVIEW report tied to the exact candidate and pipeline, while production approval remained with a human.
The MR !4 results are independently inspectable through the live agent session, completed pipeline and final bot report.
The recording uses edited timing and explanatory captions. The original repair demonstration and later release-verification results concern distinct, explicitly identified candidates; the video is not presented as continuous real-time execution or production authorization.
Lessons and scope
A successful command is insufficient if a package exit is hidden, logs are truncated or a receipt belongs to another candidate. Controls reject tampering, wrong test identities, mixed candidates, stale generations and incomplete payload inventories. The cockpit makes those distinctions visible in the developer's workflow. The live reporting work also exposed a practical integration trap: editing a bot-owned note requires permissions that creating a final note does not. We removed that unnecessary dependency and verified final publication using existing access; failed experiments remain in the MR history.
These are bounded executable witnesses, not a proof of all YAML behavior or a Lean-to-Go correspondence proof. Operator, runner, policy, verifier and compiler remain trust roots; hashes establish consistency, not authenticity against a compromised runner. Static analysis is not a vulnerability scanner; one public observation is not continuous monitoring. Repeat-safe reporting assumes one reporting workload per MR and does not claim atomic exactly-once creation across concurrent sessions. The container recipe is unexecuted. No Google Cloud bonus, speed/cost advantage or measured carbon reduction is claimed.
Next: apply the evidence lifecycle to more obligations and deployment adapters while retaining explicit approval of the exact verified outcome.

Log in or sign up for Devpost to join the conversation.