GitLab announced general availability of Orbit on October 29, 2026. The product connects software-lifecycle information, including code, merge requests, pipelines and ownership, into a queryable graph. For a team using it to investigate dependencies, an important review task is to keep the scope of the query beside the answer.
GitLab’s October 29 Orbit announcement
The announcement starts availability with GitLab.com Premium and Ultimate customers, with Self-Managed and Dedicated following over the coming weeks. Confirm access for your actual deployment before planning an evaluation. The article below is a proposed review exercise, not a report of an Orbit installation or benchmark.
Read the question and the returned rows together
GitLab’s query documentation says results contain only data the caller can access. Its API uses the token owner’s access, and agents can submit graph queries through MCP. Queries also use explicit bounds and filters; the documentation’s introductory example includes a result limit. These details belong in a reviewer’s interpretation of an answer.
Official Orbit query guide: access, filters and query examples
Try a fictional two-project review
Imagine a training workspace containing two invented projects, Web and Worker. Both depend on a fictional helper library. Reviewer A has access only to Web; Reviewer B is already authorized to inspect both projects. Define the exercise’s expected dependency list for A as Web, and its expected list for B as Web and Worker.
If A receives one matching project and B receives two, those counts need not contradict each other. They answer questions within different access scopes. A’s result alone does not establish that the library has only one dependent across the organization. This is a fictional explanation of scope, not a claim about results returned by a tested Orbit workspace.
Run any real evaluation in an approved training area with known records and existing authorized roles. Write down the expected list before querying. Have each reviewer compare results within their own permissions. An exercise should not require sharing restricted project details with someone who lacks access to them.
Save enough context to reproduce the answer
For each trial question, record the starting project or group, the dependency being investigated, the caller’s authorized scope, the submitted query and the time it ran. Ask the reviewer to inspect filters and limits before calling the returned list complete. Keep the query’s selected relationship separate from broader assumptions about what the organization considers a dependency.
For example, a question about direct callers is narrower than a question about every indirectly affected service. Agree which question the review needs. If the answer is used to plan a change, link each proposed follow-up to the evidence actually returned rather than extending the list from memory.
Use a small change to check the review method
In the fictional worksheet, add a third project called Batch to Reviewer B’s authorized scope and mark it as another user of the helper library. B’s expected list now contains three projects. A’s expected list remains Web. This changes the exercise’s records and expectations; it does not describe an actual Orbit indexing test or promise an update time.
If a real trial differs from its known expected list, record what remains unresolved: the query, scope, source record or another observed condition. Ask the platform owner to investigate with evidence. Avoid assigning a cause merely because an item is missing.
A useful dependency answer includes its boundary: which records were queried, under whose access, with which filters, and what evidence supports the next action. Preserve those details when copying an AI summary into a change-review document so the reader can assess what the answer establishes.
Check the dependency answer’s scope
