Orbit Change Impact System
GitLab Transcend Hackathon — Showcase Track
AI Catalog — Flow: https://gitlab.com/explore/ai-catalog/flows/1011664/ AI Catalog — Agent: https://gitlab.com/explore/ai-catalog/agents/1011802/ Project Repository: https://gitlab.com/gitlab-ai-hackathon/transcend/35521271
Inspiration
Every software team has experienced it. A developer changes a function signature, renames a method, or removes a parameter. Their tests pass. CI is green. The MR looks clean. They merge.
Three days later, production breaks.
Not in their service. In someone else's. A background worker in a different repo was calling that function. Nobody knew. Nobody checked. The incident post-mortem says "improve communication between teams" but the real problem is structural: cross-project dependency visibility does not exist at merge time.
This is not a discipline problem. It is an infrastructure problem. Manually tracing which projects, files, and services depend on a symbol across dozens of repositories is technically possible but practically never done. It takes too long, requires access you may not have, and there is no obvious moment in the development workflow where it fits.
GitLab Orbit exists to solve exactly this a knowledge graph that indexes the entire SDLC across projects, mapping code definitions, imports, call relationships, dependencies, and ownership. But Orbit sitting passively as a query interface is not enough. The insight needs to arrive automatically, at the right moment, with the right people already notified.
That is what the Orbit Change Impact System is.
What It Does
The Orbit Change Impact System is one cohesive system made of three cooperating components an Agent, a Flow, and a Skill all published to the GitLab AI Catalog and powered by the GitLab Orbit Knowledge Graph. A small Python CLI (brg) ties them together locally and renders a dashboard.
The three components cover the full developer lifecycle from design to merge:
| Component | Type | What it does |
|---|---|---|
| Orbit Change Impact Guardian | Agent | On-demand, conversational production-readiness review with a 0–100 risk score |
| Orbit Blast Radius Gate | Flow | Automated gate on every MR finds cross-project callers and reports risk before merge |
| critical-path-detector | Skill | Rates how architecturally critical a changed component is, as a reusable sub-task |
They all draw from the same Orbit graph (with a code-search fallback), and each can be used independently.
Component 1 — The Agent: Orbit Change Impact Guardian
The Agent (published in the AI Catalog) is the conversational, on-demand layer. It thinks like a senior staff engineer doing a production-readiness review not a general coding assistant. A developer can ask:
"What is the blast radius if I modify
auth/token_validator.py?" "Which services depend onPaymentGateway#process_transaction?" "Analyze the impact of MR !15."
It understands the change, analyzes relationships via Orbit (get_graph_schema, query_graph), and evaluates risk across five axes dependency, architectural, security, operational, and testing producing a 0–100 score. Output is structured: Change Summary, Affected Components, Blast Radius Analysis, Dependency Analysis, Potential Risks, Risk Score, Recommended Reviewers, Required Tests, and a Mitigation Checklist. When judging how important a modified component is, the Agent invokes the critical-path-detector Skill and folds its criticality into the final score.
Component 2 — The Flow: Orbit Blast Radius Gate
The Flow runs automatically when the service account is assigned as a reviewer on a merge request. No manual invocation. No commands to remember. The developer opens an MR, the service account gets assigned (via approval rules or a reviewer template), and the flow runs.
It executes its phases in sequence inside a single session:
Phase 0 — Preflight Validation Validates the MR exists and is accessible. Records the head SHA, project path, and MR state. Handles edge cases (closed MR, missing inputs) gracefully with a clear error note.
Phase 1 — Changed Symbol Extraction
Calls the GitLab REST API to get the exact MR diff. Parses every changed file and extracts code symbols — functions, classes, methods, exported constants that were added, modified, or deleted. Classifies each as SIGNATURE_CHANGED (the declaration itself changed) or BODY_ONLY (only the implementation changed). Ignores docs, configs, and test files. This distinction matters: a signature change is far more dangerous than a body change.
Phase 2 — Orbit Knowledge Graph Query
For each changed symbol, queries the GitLab Orbit Knowledge Graph using get_graph_schema and query_graph — the native built-in tools of the Duo Agent Platform. Traverses ImportedSymbol nodes and CALLS edges to find every file across the entire top-level group that references the changed symbol. These are cross-project results not just the current repo. If Orbit is unavailable, the flow falls back to group-scoped blob search automatically, so it always produces a result.
Phase 3 — Risk Assessment For each caller found by Orbit, the flow assesses three dimensions: (1) test coverage does a spec or test file exist near the caller's path? (2) ownership who owns this file per CODEOWNERS? (3) project boundary — is this caller in a different project than the MR author's? These combine into a risk score: HIGH (untested, different project, signature changed), MEDIUM (tested but external, or untested same-project), or LOW (same project with coverage).
Phase 3.5 — Dedup, Caps, and Idempotency Deduplicates results, caps at 50 displayed rows, and limits follow-up issue creation to 5 per run. Before creating any issue, checks whether one already exists for that project and MR so re-triggering the flow never creates duplicate issues.
Phase 4 — Report and Gate Posts a structured Impact Report as a merge request note with a full risk table, ownership information, and next steps. For every project with HIGH risk callers, creates a follow-up issue in the relevant team's project naming the specific affected files and callers. The developer cannot miss this it appears directly on the MR before they can merge.
Component 3 — The Skill: critical-path-detector
The Skill (critical-path-detector) is invoked by the Agent as a modular sub-task. It answers a different but related question: not "who calls this symbol" but "how architecturally important is this component?"
The Skill counts incoming and outgoing dependencies, identifies whether the component is a hub (many dependents), notes whether it sits on auth / authorization / payments / infrastructure / shared-utility paths, and classifies it as CRITICAL / HIGH / MEDIUM / LOW criticality with a matching SCORE CONTRIBUTION used as a floor for the final score. A function called by 40 other services is CRITICAL even before any change is made.
This separation keeps the architecture clean: the Skill handles component importance analysis, the Agent handles change impact assessment, and the Flow protects every MR. Both the Agent and Flow draw from the same Orbit graph. Each component can be used independently.
Tying it together — the brg CLI and dashboard
A Python companion CLI (brg, in brg-cli/) connects directly to the Orbit graph via glab orbit remote query, computes blast radius locally, and renders a self-contained HTML dashboard published to GitLab Pages. It runs the same Definition → ImportedSymbol → Project traversal as the Flow, uses only the Python standard library (zero runtime dependencies), and degrades gracefully to an empty fallback when Orbit or glab is unavailable.
How We Built It
Everything was built and tested end-to-end inside the GitLab Duo Agent Platform, against real MRs in the hackathon provisioned project.
The Flow was built iteratively, starting from a 4-component pipeline design (each phase as a separate AgentComponent). During testing we discovered a critical platform constraint: components do not share conversation history with each other. Each component runs in complete isolation. After confirming this through multiple test runs, we collapsed all four phases into a single AgentComponent, which gave the agent access to its own full session memory across all phases.
Key technical decisions:
gitlab_api_geton/changesendpoint instead of the non-existentget_merge_request_diffstool — discovered through live error logsget_graph_schemaandquery_graphas native Orbit tools, auto-wired into the Duo Agent Platform — no MCP registration required- Three separate
query_graphattempts per symbol (ImportedSymbol withidentifier_name, Definition withtoken_match, CALLS edge traversal) to maximize coverage across Orbit's schema - Group-scoped blob search as a graceful fallback when Orbit's feature flag is not yet enabled
unit_primitives: []kept minimal no Jinja templating, noduo_agent_platformprimitives because the security validator blocks HTML comments, Jinja control blocks, and several other patterns in custom flow prompts- Idempotency via pre-check on existing issues before creating new ones
The Agent was built using the same Orbit tool surface, designed for conversational invocation rather than automated pipeline execution. It uses the critical-path-detector skill as a sub-task for component importance analysis.
The Skill encapsulates the component criticality logic separately so it can be composed into other agents and flows beyond this specific use case.
The CLI (brg) mirrors the Flow's traversal in pure Python (standard library only) so the same blast-radius analysis can run locally and render a static dashboard to GitLab Pages.
All three components are published publicly in the GitLab AI Catalog.
Challenges We Ran Into
Platform constraints discovered live. The multi-component history isolation was the biggest unexpected constraint. Each component truly has no access to what previous components produced. This required rethinking the entire architecture mid-build and moving to a single-component design.
Security validator. The flow YAML security scanner blocks HTML comments, HTML tags, Jinja control blocks ({% if %}), and hidden unicode characters. Every report template had to be rewritten in plain markdown-only format.
Tool availability discovery. get_merge_request_diffs does not exist in the ambient flow toolset. orbit_query_graph is not a registered tool name. gitlab_api_post availability is unconfirmed. All of this had to be discovered empirically through live test runs and session log analysis rather than from documentation.
Orbit query endpoint. The Orbit REST API (/api/v4/orbit/query) requires POST, but only gitlab_api_get is confirmed available in ambient flows. The correct integration path is through the native get_graph_schema and query_graph tools — but these require the knowledge_graph feature flag to be enabled on the group, which is still pending for the hackathon namespace.
Feature flag dependency. The knowledge_graph feature flag is not yet enabled for gitlab-ai-hackathon/transcend. https://gitlab.com/gitlab-ai-hackathon/transcend/-/orbit returns 404. The flow's Orbit queries gracefully fall back to group-scoped code search, which still finds real cross-project callers — but native graph traversal is waiting on this flag being enabled.
Accomplishments That We're Proud Of
It actually runs end-to-end. The flow was triggered on real MRs, ran all four phases autonomously, found real callers in other hackathon participants' projects, correctly assessed risk scores, posted a structured Impact Report on the MR, created follow-up issues for affected teams, and skipped duplicate issue creation via idempotency checks all without any manual intervention.
Real cross-project detection. In a live test run, the flow found 3 cross-project call sites across 3 other projects in the hackathon group (gitlab-ai-hackathon/transcend/39324076, /32673289, /39472971). One was HIGH risk (no tests), two were MEDIUM. It created issues for the MEDIUM callers and identified an existing issue for the HIGH caller and skipped it. This is exactly the real-world scenario the flow is designed to prevent.
Graceful degradation. The system produces a useful result in every scenario Orbit available, Orbit unavailable, MR with code changes, MR with only docs, new symbols, deleted symbols, signature changes, body-only changes. No scenario produces a failure or a blank note.
Three composable components, one system. Agent + Flow + Skill are three independent, composable pieces backed by a shared CLI and dashboard. The Skill can be used in other agents. The Agent can be used for planning before an MR is even created. The Flow protects every MR automatically. Together they cover the full developer lifecycle from design to merge.
What We Learned
The GitLab Duo Agent Platform's ambient flow model is powerful but has sharp edges that only appear at runtime. Documentation describes the schema; behavior is discovered empirically. The most valuable thing we learned is that the session log is the real source of truth every tool call, every error, every agent reasoning step is visible there, and iterating from that log is faster than any other debugging approach.
We also learned that the fallback is not a consolation prize. Group-scoped blob search finding real callers across real projects in real time is genuinely useful. The Orbit graph would add structural accuracy and catch indirect dependencies that text search misses but the system delivering real value without Orbit being enabled is itself a design success.
The single most important architecture decision: one component, all phases for the Flow. The platform constraint around inter-component isolation is not obvious from the schema, but once understood it clarifies exactly how to design flows that need to carry state across multiple reasoning steps.
What's Next
Orbit full integration. Once the knowledge_graph feature flag is enabled for the group, the flow will automatically switch from code-search fallback to real Orbit graph traversal no YAML change required. The native query_graph calls are already in the prompt, already in the toolset, and already handled in the phase logic.
Approval gate enforcement. Currently the flow posts a note and creates issues but does not block the merge. The next step is wiring the flow's HIGH risk findings into GitLab's merge request approval rules — if HIGH risk callers are found, the affected team's CODEOWNERS get added as required approvers automatically.
Multi-language symbol extraction. Phase 1 currently handles Ruby, Python, JavaScript, and TypeScript well. Expanding to Go, Rust, Java, and Kotlin with language-specific AST-aware parsing (rather than keyword scanning) would reduce false positives significantly.
Proactive scanning. Instead of waiting for an MR, run the Agent proactively on a scheduled basis to flag components that have grown into architectural hubs high incoming dependency counts, no CODEOWNERS, no test coverage. Surface these before anyone touches them.
SDLC data integration. Orbit Remote indexes not just code but issues, pipelines, vulnerabilities, and deployment history. A future version of the risk scorer could factor in "this file was involved in 3 incidents in the last 6 months" or "this project has failing pipelines" making the risk score a full SDLC signal rather than a code-only one.
Built With
- GitLab Duo Agent Platform (custom agent, ambient flow, custom skill)
- GitLab Orbit Knowledge Graph (
get_graph_schema,query_graph) - GitLab REST API (
/changes,/search,/issues,/merge_requests) - GitLab AI Catalog (public flow + agent)
- YAML flow configuration (single AgentComponent architecture)
- Python (
brgCLI, standard library only) + GitLab Pages dashboard
Submitted to GitLab Transcend Hackathon — Showcase Track Flow: https://gitlab.com/explore/ai-catalog/flows/1011664/ Agent: https://gitlab.com/explore/ai-catalog/agents/1011802/ Repository: https://gitlab.com/gitlab-ai-hackathon/transcend/35521271
Log in or sign up for Devpost to join the conversation.