# Open Service Directory (OSD) and ARD

> What OSD inherits from Agentic Resource Discovery and what it adds for brand support.

[Agentic Resource Discovery (ARD)](https://agenticresourcediscovery.org/spec/) describes how to publish and find agentic resources such as MCP servers, A2A agents, and skills. OSD uses ARD to describe and discover support agents. It adds requirements for identifying the brand and checking that the brand endorses the agent. Open Service Directory (OSD) is a tool that discovers ARD entries.

## A shared discovery model

An OSD entry is an ARD entry that also meets OSD’s brand identity requirements. OSD discovers ARD entries. 

An ARD entry includes an `identifier`, a `displayName`, an artifact `type`, and either references the artifact through `url` or includes it inline through `data`. Descriptions and representative queries help registries match it to a task. 

Entries are published in an ARD manifest with an `entries` array. A client reads the manifest directly or searches a registry through ARD’s `POST /search`, which combines natural-language text with optional structured filters and returns ranked candidates.

ARD also lets publishers advertise entry sources through webpage markup and DNS. These guides use brand-domain manifests and registry search. Other advertisement mechanisms do not replace OSD’s requirement for a matching entry in the business' manifest.

## Brand identity uses the ARD extension model

OSD keeps ARD’s field names and meanings and adds two namespaced terms, bound by the entry’s `@context`:

- `osd:brandName` is the represented business's name.
- `osd:brandDomain` is the canonical domain claimed for the business, where its endorsement is published. It is a claim. The assistant still decides whether the domain belongs to the business the customer meant.

The following fictional business, Example Air, will be used in examples throughout the OSD documentation:

```json
{
  "identifier": "urn:air:airline.example:support:assistant",
  "displayName": "Example Air Support",
  "description": "Support for cancelled flights and rebooking.",
  "representativeQueries": ["My flight was cancelled", "Help me rebook my flight"],
  "type": "application/mcp-server-card+json",
  "url": "https://support.airline.example/server-card.json",
  "@context": { "osd": "https://openservicedirectory.org/ns#" },
  "osd:brandName": "Example Air",
  "osd:brandDomain": "airline.example"
}
```

Fields without the `osd:` prefix keep their ARD meanings. The confirming ARD consumer applies the ARD base context, and the entry declares only the OSD namespace. A document can be valid ARD without being a valid OSD entry. General ARD tooling can process the shared structure, but checking the `osd:brandName` and `osd:brandDomain` terms and endorsement needs OSD-aware behavior.

## OSD adds an endorsement rule

The business publishes its brand entries at `https://{osd:brandDomain}/.well-known/ard.json`. Publication endorses the agent each entry describes, even when a support platform hosts the agent on another domain. A registry candidate is endorsed only when its complete entry matches a published one. See [trust model](https://docs.openservicedirectory.org/concepts/trust-model.md#complete-entry-matching).

To make that comparison possible, OSD search responses must return complete entries. General ARD search responses may be partial. The relevance score measures query match, not trust.

## Discovery does not define the support interaction

ARD supports different resource descriptions, including MCP Server Cards and A2A Agent Cards. The `type` identifies the document format, and a compatible client follows its connection details.

OSD adds no support-call protocol. The agent defines its operations and authorization. The assistant decides which agent to use. ARD’s optional `capabilities` field is a discovery signal, not a replacement for native tool discovery or customer authorization.

## The versions identify different things

The OSD contract pins ARD v0.91 at an exact upstream revision. The OSD version identifies the OSD requirements and schemas. The ARD version identifies the specification they build on. A newer ARD draft does not change a released OSD contract.

The CLI’s package version is independent of both. An entry’s optional `version` field describes its artifact, not the OSD contract.

See [Publish a support agent](https://docs.openservicedirectory.org/guides/publish-a-support-agent.md) to create an entry and [Discover support](https://docs.openservicedirectory.org/guides/discover-support.md) to use one.