> ## Documentation Index > Fetch the complete documentation index at: https://docs.gitar.ai/llms.txt > Use this file to discover all available pages before exploring further. # Cross-Repo Analysis > Catch changes that break another repository in your organization Cross-repo analysis is enabled per organization on the **Enterprise** plan. [Contact support](mailto:support@gitar.ai?subject=Cross-Repo%20Analysis) to turn it on for your organization. ## Overview Gitar checks your pull request against other repositories in your organization and reports what the change breaks in them. Repositories are related by more than imports. A route path, an event name, or a database column that two repositories have to agree on ties them together, with no shared package between them. Every relevant repository in your organization, on every review. Nothing to link. No cap, no per-repository slots, no setup as your organization grows. A route, an event name, or an error code ties two repositories together. No shared package required. A service in a GitHub repository and a client in a GitLab repository are asserted against each other. ## What it catches | The change | Impacts | | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | A route, a wire field, an enum value, or an error code | the client still calling it or branching on the value you removed, named by repository, file, and function | | A shared CI action, workflow, or base image | the repositories whose builds go red on their next version bump | | Code that compiles against a symbol from another repository | that the symbol is not on that repository's default branch yet, only in an unmerged PR or an unpinned branch | | One side of a feature | the counterpart the other repository never got, like a UI key with no server handler or an event with no subscriber | | A table, column, or file layout | the downstream job, warehouse model, or migration that has to move with it | | A published contract, under a patch version bump | that callers auto-upgrade into the break, so it needs a major tag or a deprecation window | ## How it works It narrows the whole organization down to the repositories your change can reach. Each impact is verified against your PR before you see it. Each finding is anchored on the line in your PR that changed the contract, names the affected repository and the file and function in it that breaks, and gives your options: keep the change backward compatible, or sequence the rollout so nothing breaks at runtime. Findings are labeled **Cross-Repo** and post inline like any other [code review finding](/features/code-review). ## Coverage Coverage builds as Gitar sees more of your organization, so a review opened the day the feature is turned on may not reach everything yet. ## Naming and excluding repositories Gitar gets this right in most cases. To customize it, commit `.gitar/cross-repo.md` and describe the relationships in natural language: which repositories depend on this one, what has to stay consistent between them, and what to leave alone. ```markdown theme={null} `my-org/frontend` and `my-org/mobile` call the API this repository publishes. `my-org/data-jobs` reads the tables this repository owns. Ignore `my-org/frontend-archive`. ``` Put the file in your [configuration repository](/configuration/configuration-repository) to apply it across the organization, or in a single repository to scope it there. When both exist, the organization's rules load first and the repository's file adds to them. ## Related How findings are posted, resolved, and tracked Where the Cross-Repo category is reported across your organization The comment the Code Review section lives in What each plan includes