-
-
BOUNDARY Forge — Verified Delivery. AI repairs code, independent evidence verifies changes, and humans control release.
BOUNDARY Forge — Verified Delivery
AI can fix code. But who proves the result is actually safe to trust?
Inspiration
AI coding agents are getting remarkably good at diagnosing failures, modifying source code, and proposing repairs.
But generating a fix is not the same as verifying one.
A software candidate can have a green-looking result while the wrong source was tested, a protected file was changed, evidence belongs to another revision, or the verification process itself was weakened.
BOUNDARY Forge was built around a simple principle:
An AI agent may help repair software. It does not get to grant itself release authority.
We wanted a workflow where an AI-assisted change could move quickly while the evidence behind that change remained independently inspectable, reproducible, and tied to the exact source being evaluated.
What it does
BOUNDARY Forge is a software-source verification workbench for governed AI-assisted delivery.
It connects genuine GitLab development history with deterministic source verification, bounded behavioral testing, evidence binding, and human-controlled release decisions.
The workflow is:
Issue → AI-assisted repair → exact source candidate → deterministic verification → independent evidence → human release decision
Forge demonstrates that workflow through three adversarial judge scenarios.
SAFE — verify the genuine repair
The SAFE scenario uses a preserved GitLab Duo repair from the original BOUNDARY lineage.
Forge reconstructs the exact Git source identity, checks the protected runtime files against its pinned policy, and executes the bounded deterministic behavioral contracts through an identity-pinned oracle.
The result is PASS with evidence bound to the exact commit and tree.
UNSAFE — refuse a weakened guard
The UNSAFE candidate modifies the protected runtime guard so that it would approve unconditionally.
Forge identifies the changed protected source, names the affected file, and refuses to treat the candidate as verified.
Its behavioral tier also fails closed rather than allowing incomplete verification to become PASS.
The result is HOLD.
FORGED — reject mismatched evidence
The FORGED scenario keeps genuine source but pairs it with release evidence claiming a different commit and tree.
The source itself may be legitimate, but the evidence binding is not.
Forge detects the mismatch and returns HOLD.
A real report cannot simply be reused for another software candidate.
Operator Mode
The judge scenarios are not a separate simulated verifier.
Operator Mode uses the same verification engine against an owner-selected trusted local Git repository and exact commit SHA.
A new compatible commit can receive exact-source and behavioral verification through the same engine. Changes to protected runtime files are held for review.
Forge does not accept arbitrary remote repositories, anonymous uploads, or commands from untrusted users.
Evidence, not confidence
Every verification run produces fresh evidence containing the source commit, tree, verification checks, behavioral result, custody state, release eligibility information, and a SHA-256 digest of the resulting report.
The Evidence Explorer exposes the current session's runs, and each report can be downloaded for independent inspection.
Forge deliberately separates verification from release authority.
A fully verified candidate may become eligible for owner review, but Forge itself still surfaces the release as HOLD.
The final decision belongs to the human owner.
How we built it
BOUNDARY Forge was built on the MIT-licensed BOUNDARY codebase and developed through GitLab-based AI-assisted engineering.
GitLab Duo contributed to the preserved repair lineage. GitLab source history provides the traceable development record. Python, FastAPI, Git, pytest, and deterministic verification components implement the workbench and operator workflow.
The verification engine combines exact Git identity, protected-source policy, bounded behavioral contracts, custody checks, release-evidence binding, and SHA-256 evidence manifests.
We also built the product as a real interactive application rather than a static demonstration. The Verification Workbench, Safety Challenge, Evidence Explorer, AI Repair view, and Operator workflow all connect back to the actual verification engine.
Challenges we faced
The hardest problem was preserving independence between the thing being evaluated and the mechanism claiming that it passed.
That forced us to repeatedly challenge our own assumptions.
During development we found cases where fresh reports could accidentally wrap stale behavioral results, where containerized deployment could not execute the full behavioral tier, where an external trusted repository could pass source verification but fail behavioral verification because the engine was anchored to the wrong Git object store, and where UI controls could invoke real verification without correctly presenting the result to the user.
Those were not hidden.
We treated them as adversarial findings, corrected them, added regression coverage, and sent the resulting exact candidates back through independent review.
The deployed path was also tested inside its container rather than assuming that local success implied deployment success.
What we learned
The strongest lesson was that trust comes from reproducible evidence, not from an agent saying that its work is correct.
AI-assisted development and deterministic verification are complementary, not interchangeable.
GitLab Duo can contribute a genuine repair.
Source verification can prove which bytes are actually being evaluated.
Behavioral contracts can test bounded expected behavior.
Evidence binding can prove that a report belongs to the claimed revision.
Independent review can challenge the acceptance process itself.
And the final release decision can remain with a human owner.
Keeping those responsibilities separate makes the overall workflow stronger.
Why it matters
Small engineering teams want the speed of AI-assisted development without turning software delivery into blind trust.
BOUNDARY Forge demonstrates a practical middle ground: agents can move quickly, but important claims remain tied to source, evidence is independently inspectable, unsafe changes fail closed, and release authority stays accountable.
The goal is not to prove that every possible software change is safe.
The goal is to make a much narrower and more defensible claim:
This is the exact source we evaluated. These are the checks that actually ran. This is the evidence they produced. And no AI agent gets to turn that evidence into a release by itself.
Inspect the source. Verify the evidence. Hold the release.
Log in or sign up for Devpost to join the conversation.