Inspiration
Every developer has lived this: a merge request gets reviewed, looks clean, gets approved, gets merged. Thirty minutes later, production is struggling. CI passed. The reviewer approved it. Nobody could have known , because the danger wasn't in the diff itself, it was in how that small change connected to everything else in the system.
Existing tools like Prometheus and Grafana only tell you about problems after real users are already affected. None of them can look at a proposed change and predict the consequence before it ships.
I had already spent months building a saturation-prediction physics engine for live distributed systems , queueing theory, Gauss-Seidel solvers, stochastic fluid models, the works. When I saw GitLab Orbit's knowledge graph, the connection was obvious: Orbit can tell you what a change actually touches. My engine can tell you what happens if you stress that. Put them together, and you get a risk prediction on every merge request, automatically.
What it does
On every merge request, a pipeline:
Queries GitLab Orbit's knowledge graph traverses MergeRequest → MergeRequestDiff → MergeRequestDiffFile to find what changed, then File → IMPORTS → File to find which other services depend on those files (this becomes the "blast radius") Pulls in real signal from Orbit's Pipeline and Vulnerability nodes recent CI health and open security findings Feeds all of that into a Go physics engine that runs real queueing-theory math , Erlang-C (M/M/c) formulas, a Gauss-Seidel fixed-point solver for network-coupled service equilibrium, Little's Law for service-rate derivation Posts a plain-language risk report as a comment directly on the merge request collapse probability, blast radius, time until saturation ,before anyone clicks merge
There's also a second, simpler analysis path built purely on closed-form Erlang-C queueing theory, with zero unfitted constants built specifically so the richer model's outputs could be sanity-checked against something textbook-verifiable.
How we built it
The physics engine itself (modelling/, telemetry/, topology/) predates this hackathon it's a general-purpose saturation-prediction system I built for live, running distributed systems. What I built during this hackathon is the bridge that lets that engine answer a different kind of question: not "what is this live system doing right now," but "what would happen to this system if this specific code change goes out."
That bridge is three pieces:
orbit-agent/agent.py ,a Python agent that queries Orbit's API, with a graceful fallback to GitLab's standard Merge Request Diff API when Orbit doesn't have data for a project yet internal/agent/api/orbit_mr.go , converts Orbit's graph data into the engine's existing ServiceWindow and GraphSnapshot structures, runs the physics simulation, and formats the markdown report .gitlab-ci.yml wires it all together so it runs automatically on every merge request, with zero manual steps
I also added a real Prometheus instance into the CI pipeline (an actual server, via GitLab's service containers) and a hand-written, zero-dependency /metrics endpoint on the engine itself, so the discovery → scrape → analysis path could be demonstrated end-to-end with genuinely real telemetry, not just structural proxies.
Challenges we ran into
Orbit's API response format changed shape three times during development from a flat list, to a dictionary keyed by string indices, to a full graph format with nodes/edges and format_version: 2.1.0. Each time, the agent's parsing logic had to be rewritten to handle the new shape and stay backward compatible, since I couldn't predict which format a given environment would return. The final version normalizes all observed formats into one consistent structure before anything downstream touches it.
The harder challenge was honesty about the physics, not the plumbing. Early on, the risk reports were reporting near-100% collapse probability on every single merge request even tiny, low-risk ones. I traced it down through several layers: a server-utilization formula that wasn't proper queueing theory, a stochastic model with constants that were reasonable-looking defaults rather than anything fitted to real data, and in one case a magic constant (baselineServicePerServer = 700) silently overriding a correctly-derived value 60% of the time.
I fixed what was fixable with real math: replaced the broken utilization formula with the actual M/M/c identity ρ = λ/(c·μ), verified the core Erlang-C implementation against five independent textbook reference values (including the exact M/M/1 mathematical identity), and rebuilt collapse-probability estimation as a proper 50-trajectory Monte Carlo instead of a single noisy simulation run.
What I couldn't fix in the time available the deeper stochastic model's 15 constants aren't fitted to any real service's measured behavior yet I disclosed instead of hiding. Every single report this system generates includes an explicit calibration-status note, and the repository has a CALIBRATION.md document laying out exactly what real telemetry would be needed to fix that properly, and how.
Accomplishments that we're proud of
Catching our own bugs before a judge could. Early versions of the risk report flagged nearly every merge request as a near-certain collapse including trivial, one-line changes. Instead of shipping that, I traced it through three separate root causes (a broken utilization formula, an unfitted constant silently dominating the result, a single noisy simulation pass standing in for a probability estimate) and fixed each one with real queueing theory, not parameter tweaking.
Verifying the math independently, not just trusting that it ran. The Erlang-C formula at the core of this project was checked against five reference values computed from an independent implementation of the textbook closed-form equation including the exact M/M/1 mathematical identity, which has zero tolerance for error. It matches to six decimal places.
Handling a knowledge graph API that changed shape three times during development. Orbit's response format moved from a flat list, to a string-keyed dictionary, to a full nodes/edges graph structure over the course of building this and the agent now normalizes all of them, with a clean fallback to GitLab's standard Diff API when Orbit has no data for a project yet. The pipeline never crashes; it degrades gracefully.
A real Prometheus instance, genuinely scraping, inside the CI pipeline. Not a mock, not a stub an actual Prometheus server running as a GitLab CI service container, scraping a hand-written, zero-dependency /metrics endpoint on the engine itself. Discovery goes from ✗ prometheus to ✓ prometheus on camera.
Disclosing what isn't validated yet, instead of hiding it. The deeper stochastic physics model still has constants that aren't fitted to real production telemetry. Rather than quietly shipping confident-looking numbers, every report this system generates says so explicitly, and CALIBRATION.md lays out exactly what real data would be needed to fix that and why that's a data problem, not a code problem.
Zero new external dependencies. The entire Go physics engine Erlang-C, Gauss-Seidel solver, the stochastic fluid model, the Prometheus metrics endpoint is built on the Go standard library alone.
What we learned
That a physics-sounding number is not the same thing as a validated number, and that the difference matters more than how impressive the output looks in a demo. Testing a formula against an independent reference implementation caught real bugs that "the code runs without errors" never would have. And that disclosing a limitation clearly, in the product itself, is a stronger engineering signal than quietly shipping a number that looks more confident than it should.
What's next for Merge Request Risk Check
Multi-hop blast radius trace IMPORTS two and three levels deep, not just direct dependents Real telemetry-based calibration of the stochastic model's constants, once it's running against a production service with measurable load An optional auto-block on merge when collapse probability crosses a configurable threshold Packaging this as a formal GitLab Duo Agent Platform skill, so a developer can ask "what's the risk of this MR?" directly in natural language
Log in or sign up for Devpost to join the conversation.