Skip to content

SolveLang Process Solution

Test the landing tree once. Merge only what was tested.

Process Solution is a merge-governance control plane for GitHub teams. It builds the exact tree that will land — base plus batch together — runs one capped battery on it, and lands that tree only on FULL GREEN. Every decision is written to an audit log, and the savings are proved on a scoreboard your team can read.

The wall

Your code never leaves your infrastructure.

The control plane sees webhooks, PR metadata and test results — never a checkout. Your repositories, your code, and your self-hosted runners stay inside your world; SolveLang orchestrates the queue from metadata alone. That is the whole security story, and it stays literally true.

How it works

From install to landed code, the same five steps run for every batch.

  1. Step 1

    Install the app

    One GitHub App install on your org. Minutes. Nothing else to set up.

  2. Step 2

    Set the rules

    Plain lines in merge-rules.solve. Most teams start from our proven template and adjust the caps to their queue.

  3. Step 3

    PR opens, cheap tier

    Fast checks run at once on your runners. No full battery is burned on a pull request that has not earned it yet.

  4. Step 4

    Queue builds the combined tree

    The control plane builds the exact tree that will land — base plus batch together — instead of testing each pull request against a base it will never meet.

  5. Step 5

    One battery, capped shards

    One full run on that combined tree, split into at most six shards. Any shard can run on any free runner you own.

Green — the exact tested tree merges

On FULL GREEN, the tree that lands is the tree that was tested — the same commits, the same combination. Nothing merges that was not itself tested.

Red — the batch is bisected

The system splits the batch, finds the one guilty pull request, and ejects it to its author with the reason. The innocent pull requests still land.

Works with the checks you already run

Process Solution governs from GitHub check state — it never sits inside your CI and never parses your test reports. It is proven today on GitHub Actions, and it works with any CI that reports results to GitHub as checks or commit statuses, and any test framework whose results land as a check. If GitHub can see it red or green, the governor can govern it.

Proven on the pilot queue

  • GitHub Actions

Works by the same mechanism — any CI that reports GitHub checks

  • Azure Pipelines
  • Buildkite
  • CircleCI
  • GitLab CI (via GitHub status reporting)
  • Jenkins
  • TeamCity
  • Travis CI

Any framework whose results surface as a check — including

  • Jest
  • Vitest
  • pytest
  • PHPUnit
  • Pest
  • RSpec
  • Minitest
  • Go test
  • JUnit
  • TestNG
  • NUnit
  • MSTest
  • Playwright
  • Cypress
  • Cargo (Rust)

Don't see your CI? If it reports checks or commit statuses to GitHub, it works. If it doesn't, tell us — hello@solve-lang.com.

Proof, measured — not promised

Every number below was measured on the owner's own production queue in the Nov 3–6, 2026 audit. Design partner number one is our own companies; the queue that produced these numbers runs under these same rules today.

34.3

CI job-hours per merged PR

2,365.8 job-hours across 69 merges — the waste this product attacks.

42.4%

of all CI time was queue wait

Machines idle, pull requests stuck — capacity spent on waiting, not testing.

15 → ~1

full test runs for a 5-link chain

15 runs the old way — L(L+1)/2 for chain length L — versus about one run per landing batch.

0.3–0.5

target test runs per landed PR

The scoreboard target with batching. Stated as a target, not as a result.

The rules are readable on purpose

Governance lives in plain lines your team can read in review — not in a black box. This is the proven starting template, the same shape that governs our own queue:

merge-rules.solve

stack ≤ 6 files
shards ≤ 6 per PR · ≤ 6 per landing tree
batch 3 — 5 only when failures drop under 10%
gate FULL GREEN only
fleet your own runners only · any runner, any shard

Every cap in this template is a recommendation, not a lock — your team configures stack size, shard caps, batch size and gate strictness to your own queue. The floor that never moves: fail-closed on unresolvable state, a written reason for every merge and block, and your code never leaves your infrastructure.

The rules are the readable part. The product is that they are enforced on every landing — and that every enforcement is audited.

Every merge has a why

Decision audit log

Every merge and every block writes its reason to the decision audit log: which tree was tested, which battery ran, and why a pull request was ejected. When something is questioned, the answer is a lookup, not an investigation — and the log is exportable for your reviewers.

The scoreboard

merges per day · job-hours per merged PR · runs per landed PR · queue-wait share · fleet state — read daily, before and after. The scoreboard is the renewal: savings are audited numbers your own queue produced, not a sales claim.

When a check goes red

Classified, not just counted

Every red is sorted before anything moves: a real defect goes back to its author with the reason; proven infrastructure noise earns exactly one rerun — never an open-ended retry loop. Both outcomes are written to the decision audit log, so a blocked merge always has a readable why.

Become a design partner

We are onboarding a small number of design-partner teams. Your queue runs on your runners; we bring the control plane, the rules template, and the scoreboard. Write to us and tell us what your merge queue costs you today.

hello@solve-lang.com