# Discovery flow

> Brand identity, discovery sources, endorsement outcomes, and agent selection.

During discovery, the assistant decides which business the customer means, where to look for its
support agents, and whether a candidate fits the request. See
[How OSD works](https://cautious-adventure-v6loy75.pages.github.io/getting-started/how-osd-works.md) for the publishing-to-connection flow and
[Discover support](https://cautious-adventure-v6loy75.pages.github.io/guides/discover-support.md) for HTTP examples.

```mermaid
flowchart TD
    I["Identify the brand and support need"] -->|Known domain| B["Retrieve and validate brand manifest"]
    I -->|Registry search| R["Receive candidate entries"]
    R --> V["Compare candidate with brand manifest"]
    V -->|Match| S["Assess suitability and select"]
    B -->|Valid manifest| S
    B -->|Unavailable or invalid| N["Retry or use another support route"]
    V -->|Mismatch or inconclusive| N
    S --> C["Read the card and connect to the agent"]
```

## Identify the intended brand

The assistant starts with the customer’s request and context. An itinerary might identify Example Air for a cancelled flight. A request naming only a product or an ambiguous business may need clarification.

Mapping a brand name to its canonical domain is the assistant’s job. A candidate’s `osd:brandDomain` is a claim to check, not proof of the right business. Keep the discovery query to the brand and task. Customer records belong in the later, authorized interaction.

## Obtain candidate entries

If the brand’s canonical domain is known, the assistant can retrieve and validate
`https://{osd:brandDomain}/.well-known/ard.json` directly. Entries read from the intended brand’s
validated manifest are endorsed by that publication.

Otherwise, search a configured registry by brand or support need. Request an exact OSD contract
version, check the response’s declared version, and validate the body. Each result includes a complete
entry, a relevance `score`, and the registry `source`. These are candidates to check, not proof of
endorsement.

Consider entries that fit the task and use an artifact type the client supports. If none fits,
refine the query or offer another support route.

## Check endorsement and suitability

Compare each registry candidate with the intended brand’s manifest. Only a complete match counts.
See the [trust model](https://cautious-adventure-v6loy75.pages.github.io/concepts/trust-model.md#complete-entry-matching) for the comparison rule.

- **Match:** The complete entry matches a published entry. Assess whether the agent fits the task.
- **Mismatch:** The manifest is valid, but no entry matches. Do not treat the candidate as endorsed.
  Check another candidate or the brand’s published alternatives.
- **Inconclusive:** The manifest could not be retrieved or validated. Do not treat the candidate as
  endorsed. Retry the check or offer another support route.

Several endorsed agents can serve different needs. Choose one that fits the request under the host’s
trust policy. If the brand or agent is still ambiguous, ask the customer before connecting.

## Connect after discovery

Read the selected entry’s artifact through `url` or inline `data` and follow its protocol-specific
connection details, such as an MCP Server Card or an A2A Agent Card. The agent handles authentication, operations, and customer permissions. The assistant obtains any confirmation the action requires. Changing a booking or opening a ticket happens over this connection. Discovery itself does not authenticate the customer or authorize those actions.