> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tastelabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Brand adherence

> Score how well a page follows a reference site's brand

Extraction answers "what does this brand look like?". **Brand adherence** answers the follow-up: "does this page actually follow it?". You give two URLs, a reference site whose brand is the standard and a page to judge against it, and the engine returns a verdict: one score, prose recommendations, and concrete fixes.

Use it to check a rebuild against the original, score a generated page against the brand it was prompted with, or measure how far a redesign drifted.

Like extraction, adherence is **asynchronous**: you create a job, poll it, and read the verdict when it completes.

## The flow

<Steps>
  <Step title="Create the job">
    Call [`POST /judge/brand-adherence`](/api-reference/endpoint/create-brand-adherence) with the two URLs. You receive a `job_id` and a `202 Accepted` response.

    ```bash theme={null}
    curl -X POST https://api.tastelabs.com/judge/brand-adherence \
      -H "X-API-Key: your-api-key" \
      -H "Content-Type: application/json" \
      -d '{"reference_url": "https://stripe.com", "source_url": "https://staging.example.com"}'
    ```

    Both URLs are extracted automatically, and a recent extraction of either side is reused. You do not need to create submissions first.
  </Step>

  <Step title="Poll the job">
    Call [`GET /judge/brand-adherence/{job_id}`](/api-reference/endpoint/get-brand-adherence-job) until `status` is `completed`. Stop on `failed` and read `error` for the reason. In-progress statuses are `accepted`, `extracting`, and `judging`; `current_step` names the exact pipeline stage.

    ```bash theme={null}
    curl https://api.tastelabs.com/judge/brand-adherence/JOB_ID \
      -H "X-API-Key: your-api-key"
    ```
  </Step>

  <Step title="Read the verdict">
    Call [`GET /judge/brand-adherence/{job_id}/result`](/api-reference/endpoint/get-brand-adherence-verdict).

    ```bash theme={null}
    curl https://api.tastelabs.com/judge/brand-adherence/JOB_ID/result \
      -H "X-API-Key: your-api-key"
    ```

    The verdict streams in: while the job runs you may receive a partial verdict, and before the first component lands you receive `409 NOT_READY`. A failed job returns `424` and will never produce a verdict, so stop polling on it.
  </Step>
</Steps>

## The verdict

| Field             | Holds                                                                                                                                                                    |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `score`           | One number from 0 to 1: how well the source page follows the reference brand. `null` until the run has produced at least one scored component.                           |
| `recommendations` | Recommendation strings, worst-first, with exact target values. Capped at 20.                                                                                             |
| `fixes`           | Structured fix objects, worst-first, capped at 20. Each carries an `action` discriminator (e.g. `snap_to_token`, `add_color_token`) plus fields specific to that action. |

## Reuse

The pipeline reuses work where it can: the response's `cache_hit` object reports, per side, whether the design extraction and the verifier extraction were served from existing artifacts, and whether the final pair report was reused.

To re-read a verdict, call the result endpoint with the existing `job_id` instead of creating the job again. Find past jobs with [`GET /judge/brand-adherence`](/api-reference/endpoint/list-brand-adherence-jobs): filter with `status` or `q` (free text over both sides' URLs), and read `total` for the size of the filtered set. Each row carries `api_key_name`, so you can attribute runs to a key.

## Visibility

Jobs are **private by default**: only the owner can read them. [`PATCH /judge/brand-adherence/{job_id}/visibility`](/api-reference/endpoint/update-brand-adherence-visibility) with `{"is_public": true}` makes the verdict readable from the result endpoint **without authentication**, so you can share it. Only the owner can change a job's visibility.

## From your agent

The same flow is exposed as [MCP tools](/ai-tools/mcp): `verify_brand_adherence(reference_url, source_url)`, `poll_brand_adherence(adherence_job_id)`, `get_brand_adherence_result(adherence_job_id)`, and `list_brand_adherence_jobs(status?, limit, offset)`. An agent can generate a page from an extraction, then verify its own output against the reference brand and apply the returned fixes. [Verification in an agent loop](/use-cases/agent-loop) walks that pattern, including what to feed back and when to stop.

## Next steps

<CardGroup cols={2}>
  <Card title="Check brand adherence" icon="list-check" href="/use-cases/brand-adherence">
    The workflow end to end, with a full example.
  </Card>

  <Card title="Verification in an agent loop" icon="rotate" href="/use-cases/agent-loop">
    Feed the verdict back to the agent that built the page.
  </Card>

  <Card title="Create brand-adherence job" icon="scale-balanced" href="/api-reference/endpoint/create-brand-adherence">
    The endpoint reference, with an interactive playground.
  </Card>

  <Card title="MCP server" icon="plug" href="/ai-tools/mcp">
    Give your coding agent the same verification tools.
  </Card>
</CardGroup>