Jointly

Two green PRs. One hidden collision. Jointly finds it before merge.

Comment

Inspiration

Modern development teams increasingly use AI agents and parallel contributors to build features faster. But faster implementation creates a new risk: two changes can each pass code review and testing independently, merge without a Git conflict, and still break the product when their assumptions interact.

That gap inspired Jointly.

Our demonstration uses a checkout system where one change adds percentage coupons while another adds payment retry validation. Both branches pass their tests. The combined code also merges cleanly. However, the coupon changes the meaning of Order.total, while payment retry still assumes the original accounting rule. Only a test derived from both changes’ intended behavior reveals the collision.

What it does

Jointly is an intent-aware pre-merge verification system for independently developed changes.

It:

  1. Freezes two changes and their common Git base.
  2. Creates isolated base, change-A, change-B, and combined workspaces.
  3. Runs each change’s existing tests.
  4. Extracts structured intent and requirement contracts.
  5. Identifies high-risk interaction surfaces.
  6. Generates a focused cross-change test.
  7. Distinguishes a real assertion failure from invalid tests, setup failures, timeouts, or environmental errors.
  8. Proposes a repair inside the isolated combined workspace.
  9. Re-runs the interaction test, regressions, and stability checks.
  10. Produces an auditable Merge Safety Passport.

The governing principle is simple:

AI proposes. Evidence decides.

Jointly does not treat model confidence as proof. Every safety claim must be supported by deterministic execution and recorded evidence.

How we built it

Jointly is a TypeScript and Node.js monorepo with:

  • a deterministic verification core;
  • an IBM Bob IDE mode with five project Skills;
  • nine typed MCP tools for bounded repository operations;
  • four-workspace Git isolation;
  • structured intent, hypothesis, test, repair, and evidence contracts;
  • a watsonx.ai transport adapter with mocked and offline contract coverage;
  • a Vite evidence dashboard;
  • Zod validation for tool inputs and evidence artifacts;
  • Vitest regression and failure-classification tests;
  • a gated Merge Safety Passport.

IBM Bob assisted with planning, development, repository investigation, and the initial watsonx adapter implementation. In the working Bob workflow, Bob proposes intent contracts, interaction hypotheses, tests, and repairs while Jointly’s MCP tools control Git operations, command execution, evidence persistence, and verdict generation.

The deployed website presents the investigation as an evidence-driven narrative: change overview, intent map, hidden collision, repair verification, passport, and roadmap.

Challenges we faced

The hardest problem was preventing a failed generated test from being mistaken for a confirmed collision. A missing import, syntax error, timeout, skipped test, or broken fixture is not evidence of incompatible behavior. We added structured execution records and explicit classifications so only a meaningful assertion tied to the stated hypothesis can confirm a collision.

We also had to preserve both usefulness and safety. Repository actions are bounded, commands are allowlisted, source branches remain untouched, and repairs are evaluated only in an isolated combined workspace.

Another challenge was being precise about what is demonstrated. The Bob IDE and MCP workflow, deterministic core, evidence dashboard, and offline-tested watsonx adapter exist today. Live hosted watsonx orchestration, credential-separated cloud execution, multi-user authorization, and publication of an approved integration pull request remain roadmap milestones rather than completed claims.

What we learned

We learned that merge safety is not primarily a text-merging problem. It is a problem of reconciling assumptions.

Existing tests usually verify what each contributor anticipated individually. Jointly adds the missing question:

What test would neither contributor think to write alone?

We also learned that trustworthy AI development requires a hard separation between probabilistic proposals and deterministic decisions. Models are valuable for forming hypotheses, but reproducible execution must decide whether those hypotheses are true.

What’s next

Our next milestone is an authorized hosted workflow that connects live watsonx.ai reasoning and GitHub repository selection to the same deterministic verification core.

Before any hosted release, Jointly will require:

  • credential-separated execution with canary-secret tests;
  • filesystem, process, and network isolation;
  • authorization between users, repositories, runs, and artifacts;
  • exact candidate and source-ref revalidation;
  • explicit human approval before publishing one integration pull request;
  • continued regression coverage for the IBM Bob IDE + MCP workflow.

Longer term, we plan to support more languages, test frameworks, repository profiles, and interaction graphs involving more than two changes.

Jointly: Two green PRs. One hidden collision. Evidence before merge.

Built With

Share this project:

Updates

Submission history