Orbit Risk Router

Inspiration

Reviewers guess a merge request's risk from the diff. But in a large repo the danger isn't the diff — it's the hidden dependency graph around it: who else imports this code, what pipelines it breaks, what vulnerabilities sit nearby, and who actually knows this area. GitLab Orbit exposes exactly that graph, so we built the thing a real team wants on every MR: an automated merge-risk router.

What it does

Orbit Risk Router is a GitLab Duo agent (with a flow variant) published to the AI Catalog. You hand it a merge request — or, as a flow, it fires when an MR is marked ready — and it:

1. Reads the changed files.
2. Queries Orbit's graph for blast radius (who imports the changed code, which other projects are reached), recent related MRs, failed pipelines nearby, open high/critical vulnerabilities, and the most relevant reviewers.
3. Computes a transparent, deterministic risk score (not an LLM guess) and routes the MR: LOW / MEDIUM / HIGH / SECURITY-RELEASE-BLOCKER.
4. Acts on the MR: applies an orbit-risk::<level> label, posts a reviewer-ready impact report with the full evidence chain, requests the right reviewer, and opens a targeted test/security checklist for risky changes.

What changes for the developer: instead of guessing "who should review this and what could break?", the MR answers it automatically in seconds — with graph evidence attached — so risky changes get caught and routed before merge, not after. Every recommendation traces back to a specific graph entity — a visible evidence chain from graph query → decision → action, never hand-wavy AI.

How we built it

• A Custom Agent published to the AI Catalog — a system prompt that gathers Orbit signals via query_graph/get_graph_schema and acts through built-in tools (create_merge_request_note, update_merge_request, create_issue). A custom flow (flow registry v1 YAML) is included in the repo as the auto-triggered variant (MR-ready / assign-reviewer / mention).
• A deterministic scoring engine in Python — the auditable heart. Counts are scored in bands (0–4) so no single noisy signal dominates.
• A pluggable Orbit query layer with three backends behind one contract: Remote (the live POST /api/v4/orbit/query graph), Local (DuckDB code graph), and Mock (recorded fixtures for offline/reproducible demos).
• A GitLab action layer (dry-run by default; --apply mutates).
• An Orbit query-recipe skill (SKILL.md) and the recommended quality signals: AGENTS.md + .gitlab/duo/agent-config.yml.

Verified on real Orbit data

We ran it live against a real MR (an auth/session.py change) in the hackathon group's indexed graph. Every signal came from the live Orbit graph: the real importers (middleware.py, gateway/app.py, tests/test_session.py), real related MRs, real failed pipelines, and a reviewer resolved from the graph — routed to SECURITY/RELEASE BLOCKER. (The repo's sample fixture is an anonymized capture of that run.)

Challenges we ran into

• Discovering the real Orbit response envelope (result.nodes, format 2.1.0) and that queries must be filtered/scoped by project_id — unscoped traversals over a large shared graph time out.
• Avoiding cross-project "fork noise" in a shared graph (many copies of the same sample), solved by qualified module fragments + same-top-level-group scoping.
• Keeping the risk decision transparent and bounded with band-based scoring.

Accomplishments we're proud of

A narrow, polished, graph-native workflow that does something real on every MR — verified end-to-end on live Orbit data, with graceful degradation when a backend is unavailable, and a clean evidence-first report.

What we learned

Orbit's edge is connecting code context to owners, review history, CI, and security state — cross-domain reasoning a plain code search can't do.

What's next

Inline diff-anchored comments, learned reviewer ranking from merge history, and a "risk trend" view across a project's recent MRs.

Built With

• duckdb
• gitlab-duo-agent-platform
• gitlab-orbit
• gitlab-rest-api
• python