Appearance
Provider request settings
Settings → Providers, needing provider_configuration.view to read and provider_configuration.manage to change.
What Verity declares to Elm on every Yakeen request: the usage code it queries under, and the operator id — the commercial registration the enquiry is made under. Neither is a secret. They identify the enquirer to a government registry.
Why this screen exists
These two values are fixed by the Yakeen contract. They are not issued with the Elm credentials and they appear in no provider portal, so there is nowhere to look them up if you do not have the contract in front of you.
They were environment variables, and required ones: a deployment holding every credential Elm issued was still refused on every call with "ELM_USAGE_CODE is not set". The obvious response — copy the placeholder from .env.example — is how staging came to send the literal string replace-me to Yakeen and get back "replace-me is not valid usage-code", a request error for what was really a configuration error.
Both now default in code to the contract values. This screen exists for the case where an account genuinely queries under a different registration, and so that the values can be read back without shell access to a container.
In effect now
The top of the screen states what the next Elm request will carry, and where each value came from:
| Source | Means |
|---|---|
| Set here | Somebody typed it into this screen, for this account |
From ELM_USAGE_CODE / ELM_OPERATOR_ID | The deployment injected it |
| Contract default | Nothing was set, so the value from the Yakeen contract is used |
Strongest first: an account setting beats an environment variable, which beats the contract default.
The source label is the point
A blank field on a working provider looks exactly like a blank field on a broken one. Without knowing which of the three sources won, you cannot tell whether typing here changed anything — so the screen says, and it reads the answer from the same resolver the request reads it from.
Overriding for this account
Fill a field in only if this account queries Yakeen under a different entitlement or registration.
| Field | Notes |
|---|---|
| Elm usage code | The purpose the contract is licensed to query under. Yakeen rejects a request whose usage code is not on the contract |
| Elm operator id | The commercial registration the enquiry is attributed to |
Neither may contain a space. Both go out as HTTP header values, and a stray space arrives at Yakeen as a different string than the one on screen — rejected with an error about the request rather than about the setting, which is the hardest kind to trace back here.
Clearing a field is how you return to the default
An empty field means whatever the code falls back to, not send an empty header. There is no way to make Verity send a blank usage code, because a blank one is never the right answer.
An account that never opens this screen has no stored row at all. Reading the page does not create one, so Elm keeps working on the defaults whether or not anyone has been here.
What is audited
Every change records the old and new values in Audit activity as provider_configuration.changed.
The values are recorded rather than redacted. Neither is a secret, and the row itself only holds the current answer — "who changed what we declared to Yakeen, and when" is a question an auditor asks that only the trail can answer.
Permissions
Its own pair rather than reusing api_key.manage. An account may well want the person who rotates API credentials to be a different person from the one who declares which registration is asking, and a permission that already exists cannot be narrowed later without taking it away from whoever holds it.
provider_configuration.manage needs authority in every country, not one. What these values declare applies to every request the account makes, wherever it operates — see countries.
Both are granted by default to whichever role templates already hold api_key.manage, which is Integrations Admin and Operations Admin in a stock account.
Where this does not apply
The smoke runner has no account, so it resolves from the environment and then the contract defaults. Setting ELM_USAGE_CODE / ELM_OPERATOR_ID is still the right move for that path, and only that path. See the provider operability runbook in the repository.