# `conform.refused`

The conformance suite wasn't sent to the provider's live API, because the app has no connection to the package, nothing sets the connection's credential or address, or `ai:` doesn't ask its models through it.

Area 14, [Tools](/docs/tooling.md); not declinable; the next step is usually the human's.

## Why Jadpo refuses it

`jadpo package conform <package> ai --live` sends the `ai` capability's
cases to the provider's own API, so a package is proved against what the
provider answers today rather than against its recordings. It sends them
through the app's own connection to the package, with that connection's
credential and address, and asks the models the app's `ai:` names, so
the run proves what the app itself will send.

Without those, the only thing it could send is a stand-in key to a
guessed address, and a failure would say nothing about the package.
Jadpo won't set a credential for you: the key decides which account at
the provider pays for the calls, and it is a secret only you hold.

## What it looks like

An app that asks its models through its own provider package, Acme
Models, whose key `ACME_KEY` gives:













config.jadpo:

```jadpo
config {
    acme_host: Url {
        default: "https://api.acme-models.example"
    }
    acme_key: Text {
        secret: true
    }
    drafting_model: ModelId {
        default: "acme/acme-small-1"
    }
}
```

app.jadpo:

```jadpo
application {
    connections: {
        acme: {
            package: AcmeModels.v1
            domains: [support]
            credential: config.acme_key
            host: config.acme_host
        }
    }
    ai: {
        connection: acme
        models: {
            default: config.drafting_model
        }
        limits: {
            per_day: {
                tokens: 2000000
            }
        }
    }
}
```

Nothing on this machine sets `ACME_KEY`, so the live run is refused
before anything is sent:

```sh
jadpo package conform acme_models ai --live
```

```text
error: `acme` has nothing set for the provider's API
  reason: `--live` sends the suite to the provider's API with `acme`'s credential and address, and nothing sets `ACME_KEY`, so only a stand-in would be sent.
  next: Set `ACME_KEY` in `.env.local` to the provider's, then run it again (human)
  rule: conform.refused
  help: https://jadpo.dev/docs/errors/conform.refused
```

`(human)` at the end of the `next:` line tells your coding agent to stop
and ask you which fix you want, because the choice is yours to make: it
decides which of your accounts at Acme the suite's calls are made with.

## How to fix it

The question is whether you meant to call Acme's API.

**If you did**, set the key, then run the suite again:

```sh
jadpo config set acme_key
jadpo package conform acme_models ai --live
```

`jadpo config set` asks for the key without showing what you type and
saves it in `.env.local`, which is never committed. The suite's cases
then go to `https://api.acme-models.example` with it.

**If you didn't**, run the suite without `--live`:

```sh
jadpo package conform acme_models ai
```

It then runs against the package's recordings and a local fake, and
nothing leaves your machine.

## Related

- [`jadpo package conform`](/docs/commands-for-packages.md#jadpo-package-conform)
- [The conformance suite](/docs/the-conformance-suite.md)
- [`jadpo config set` and `jadpo config check`](/docs/commands-for-the-database-settings-and-translations.md#jadpo-config-set-and-jadpo-config-check)