The Ontology Layer · Reference

Providers

The external systems a source pulls from, and how they are named.

A provider is the external system a source pulls from. Where a source is a *kind* of knowledge (work items, commits, wiki), a provider is *whose* — GitHub versus Azure DevOps versus Jira.

One source can span several providers. work_items, commits, and prs all read from whichever VCS a repository lives on; jira reads from Jira; database reads from a connected SQL or Mongo database. Filtering by provider lets you ask "issues, but only the ones in Azure DevOps."

The provider vocabulary

text

VCS providers:        github | gitlab | azure_devops
Credential providers: github | gitlab | azure_devops | jira | confluence
Binding providers:    github | gitlab | azure_devops | jira | confluence | database

The provider of a repository is detected from its URL host — github.com to github, dev.azure.com (or *.visualstudio.com) to azure_devops, gitlab.com to gitlab. Both HTTPS and SSH-style URLs are handled.

Filtering by provider

Every search and activity call accepts a providers filter alongside sources:

json

{ "query": "login regression", "sources": ["work_items"], "providers": ["azure_devops"] }

Adding a provider is adding a retriever

There is no per-provider endpoint. A provider is wired in behind a source retriever, and once registered it appears in every discover, search, fetch, and activity call automatically. This is the same extensibility rule as sources: the contract never grows.

Next: Discover.