Skip to main content
Every resource in AI Explorer has an owner — the team or person responsible for maintaining it. Ownership determines who shows up in the “Owner” column when browsing resources, and lets teams filter for resources they maintain. AI Explorer resolves ownership automatically. You don’t need to configure anything for it to work, but understanding the resolution order helps you control what shows up.

​
How ownership is resolved

When AI Explorer discovers a resource, it determines the owner by working through the following sources in order. It stops as soon as it finds a match in your Backstage catalog.

​
1. The resource manifest

Each resource type can declare an owner directly in its manifest: When a manifest includes an owner, AI Explorer looks for a matching user or group in your Backstage catalog — first by name, then by display name. For marketplace entries, it also checks by email address.

​
2. CODEOWNERS

If the manifest doesn’t specify an owner, or the specified value doesn’t match anyone in the catalog, AI Explorer falls back to your repository’s CODEOWNERS file. It finds the team or person responsible for the resource’s file path and matches them against your catalog. This is often the most reliable fallback since most organizations already maintain CODEOWNERS as part of their development workflow.

​
3. Repository metadata

If there is no CODEOWNERS match, AI Explorer looks at the repository’s root catalog-info.yaml for a declared owner.

​
4. Repository organization

As a final fallback, the GitHub organization that owns the repository is used.

​
Tips for accurate ownership

  • Set an explicit owner in the manifest — this is the most direct way to ensure the correct team is assigned. Use a name that matches a user or group in your Backstage catalog.
  • Keep your catalog up to date — AI Explorer matches manifest values against the users and groups registered in your catalog. If a team has been renamed or a person has left, ownership may not resolve correctly.
  • Maintain your CODEOWNERS file — this provides reliable ownership fallback for resources that don’t declare an owner, and is likely already part of your workflow.