PARITY 3.0 — Autonomous Migration Assurance
AI can propose the migration. PARITY makes it prove the migration.
Inspiration
Migrating from Jenkins to GitLab CI is more than translating a Jenkinsfile into YAML. A pipeline can appear valid and even pass a build while silently losing critical operational guarantees.
What happens if a migration drops an always cleanup action, changes branch restrictions, or fails to preserve artifact fingerprinting?
PARITY 3.0 was built to address this gap: migration correctness should be supported by verifiable evidence, not just plausible generated configuration.
What it does
PARITY 3.0 is an AI-assisted migration assurance engine that combines deterministic verification, evidence generation, CI enforcement, and GitLab Duo feedback.
Its workflow has five stages:
- Analyze: Examine Jenkins-to-GitLab CI migration behavior.
- Verify: Compare modeled operational guarantees and detect unsupported or missing behavior.
- Prove: Generate structured verification evidence, witness information, and ProofChain receipts.
- Enforce: Apply a GitLab CI merge-request gate that blocks migrations failing assurance checks.
- Guide: Use GitLab Duo to provide evidence-backed advisory feedback without overriding the deterministic CI decision.
The result is a migration review process where an unsafe change cannot pass the configured assurance gate merely because its YAML looks correct.
How we built it
We implemented a deterministic verification and evidence workflow and integrated it into a real GitLab merge request.
The GitLab CI gate evaluates the generated evidence and produces a PASS or BLOCK decision. In our demonstrated MR !8, the decision is BLOCK because required migration behavior was not preserved.
A real GitLab Duo agent session reviews the available evidence and posts advisory feedback to the merge request. The agent supports developer understanding, while the CI gate remains the enforcement authority.
We also built a Trust Challenge to test whether forged PASS claims could bypass the assurance process.
Challenges we faced
1. Distinguishing syntactic validity from behavioral preservation. A successful YAML conversion does not establish that cleanup, branch restrictions, and artifact semantics have been preserved.
2. Making evidence independently checkable. Verification results need structured findings and traceable evidence rather than an unsupported AI confidence statement.
3. Defining the trust boundary between AI and CI. GitLab Duo can interpret evidence and recommend next steps, but it must not override a deterministic BLOCK decision.
4. Testing adversarial evidence. We examined forged PASS attempts and identified the limitations of relying on a standalone agent-sandbox checker.
Accomplishments
- 999 automated tests passing in the reported project test suite.
- A working GitLab CI merge-request assurance gate.
- A real MR demonstrating a justified BLOCK verdict.
- A completed GitLab Duo agent session with evidence-backed feedback.
- A Trust Challenge whose full verification flow rejected 5 out of 5 forged PASS attempts.
- A public, read-only evidence report for inspection.
What we learned
AI is valuable for analyzing and explaining migration issues, but its conclusions should be separated from enforcement.
We also learned that evidence integrity and verification scope must be described precisely. ProofChain uses hashes for integrity checks, not digital signatures. PARITY checks modeled pipeline behavior and does not claim complete runtime equivalence.
The standalone Duo-sandbox checker can be misled by false job-status inputs; the full CI-controlled verification process provides the stronger enforcement boundary.
What's next
We plan to extend migration behavior coverage, strengthen evidence provenance, improve remediation guidance, and explore runtime validation for additional assurance.
Our goal is to make CI/CD migration safer, more explainable, and easier to audit — with AI helping developers and deterministic checks enforcing the rules.
Explore the project
- PARITY 3.0 source code
- Real GitLab Merge Request !8
- GitLab Duo agent session
- Trust Challenge evidence report
The PARITY 3.0 implementation is on the linked feature branch. MR !8 intentionally remains unmerged because the demonstrated CI gate blocks behaviour loss.
Log in or sign up for Devpost to join the conversation.