Draft: docs(security): clarify Orbit is deterministic and GitLab does not train on Orbit data
What does this MR do and why?
Adds a "Data handling and AI" section to the Orbit Remote security page (docs/source/remote/security.md), covering three questions that come up repeatedly from customers evaluating Orbit:
- Is Orbit deterministic? Yes. Orbit is a data API that compiles JSON DSL to ClickHouse SQL. There is no LLM or model inference behind queries.
- Does GitLab train models on Orbit data? No. GitLab does not train generative AI models on the indexed graph, source code, SDLC objects, or query inputs/outputs. AI vendors are contractually barred from training on customer data.
- Where does the data live? ClickHouse on GitLab-managed infrastructure in
us-east1(South Carolina). Same compliance posture as other SaaS ClickHouse features (Advanced Search, CI/CD analytics). Contractual residency guarantees are a GitLab Dedicated feature.
This came up in a customer evaluation conversation where the Orbit team confirmed these points verbally. Putting them in the docs gives customers and sales a citable, public reference.
Related Issues
Raised from a customer evaluation conversation (Slack thread, internal).
Testing
Documentation-only change. No code changes.
Performance Analysis
- This merge request does not introduce any performance regression. If a performance regression is expected, explain why.
Agent context — long-form analysis, file-by-file walkthroughs, profiler output, alternatives considered
File changed: docs/source/remote/security.md
New section added: ## Data handling and AI with three subsections:
### Deterministic query engine— explains no LLM/inference, JSON DSL → ClickHouse SQL pipeline### No model training on your data— states no training on graph, code, SDLC, or query I/O; vendor contractual commitment; same posture as rest of GitLab SaaS AI### Data residency—us-east1, same ClickHouse compliance as Advanced Search and CI/CD analytics; Dedicated for contractual guarantees
Placement: Between ## Security architecture and ## Programmatic access — logical flow from "how access is controlled" → "what happens to the data" → "how to connect programmatically".
Front matter description updated to include "data handling and AI".
Alternatives considered: Adding to how-it-works.md instead. Chose security.md because customers asking "do you train on my data?" are asking a security/compliance question, not an architecture question.
%{all_commits}