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

# Studio model and provider readiness

> Current model settings surface and unapproved provider-key and per-job gaps.

This page records what the customer Studio API exposes for model settings today and
what remains unapproved for provider keys and per-job model choices. It is a
readiness inventory; missing actions below have no callable customer route or API
operation.

## Current customer API

The published [model settings contract](./model-settings) documents three current
operations: `get-model-settings`, `update-model-settings`, and
`list-tied-hosted-models`. They share the account-scoped
`/api/v1/accounts/{account_id}/model_settings` resource. The authenticated URL
account member must have the `model_settings` feature enabled and be an
administrator. The account is resolved from the authenticated membership, and
reads and writes are scoped to that account.

The settings read returns the effective routing profile, plan tier, lock version,
profile catalogue, and Tied-managed override role names. The hosted catalogue is
filtered by the account's server-derived plan tier. The profile update accepts
only top-level `profile` and `lock_version`, persists the profile and audit event
atomically, and refuses stale versions, invalid or unavailable profiles, and
customer changes to a staff-pinned profile. It does not accept provider keys or
per-job model selections. The existing contract and its tests establish these
behaviors; they do not establish any key-management or per-job customer endpoint.

Staff roster pins and internal provider-key storage are separate implementation
surfaces. Their existence does not provide customer Studio routes or authorize
customer API exposure. Current model settings responses include no provider
credential, key reference, model override selection, key prefix, or digest.

## Requested actions with no current customer operation

Every row below was checked against the routes and OpenAPI at source revision
`637fcc97d3e471e82b0b630161fd75b680c4ed22` on 2026-10-22. `ENG-5876` owns the
missing runtime behavior and I-30 reconciliation. These entries are proposals,
not an operational register or harness debt. No path, operation ID, scope, or
runtime behavior is approved by this inventory.

| Requested action | Current route / operation | Current reuse boundary | Required future proof |
| - | - | - | - |
| `addKey` | None | Existing settings actions do not accept credentials. Internal key storage is not a customer endpoint. | Classify the credential write; return write-only state; return only configured flags; prove no key or prefix in responses, logs, or events; prove prior state is unchanged for invalid key/model or refusal. |
| `updateKey` | None | Existing settings actions do not accept credentials. | Define whether update replaces a credential and its concurrency rules; prove write-only responses, configured-flag-only output, no key or prefix in responses/logs/events, and unchanged prior state on invalid input or refusal. |
| `rotateKey` | None | Internal rotation helpers do not define customer route semantics. | Define old/new credential overlap and failure behavior, rate limits, write-only responses, no key or prefix in responses/logs/events, and what happens to jobs already routed through the key. |
| `removeKey` | None | Internal revocation behavior does not define customer route semantics. | Define confirmation and revocation behavior, rate limits, write-only responses, no key or prefix in responses/logs/events, and what happens to jobs already routed through the key. |
| `verifyKey` | None | Existing settings and hosted-catalog reads do not verify customer credentials. | Classify verification as a credential-bearing write; document outbound provider effects, allowlist and rate limits; return only configured/verification flags; prove no key or prefix in responses/logs/events and unchanged prior state on invalid input or refusal. |
| Per-job read/list | None | Current settings show profile and Tied-managed override role names only. They do not return private provider/model selections. | Define an account-scoped read and safe response fields. Visibility through MCP is only a candidate and requires explicit P4 scope and P9 external-provider data-flow approval. |
| Per-job set | None | Current profile update changes the account profile only; it does not set a job's provider or model. | Define allowed roles/models, validation, audit, concurrency, and unchanged prior state on invalid input or refusal. Coordinate with direct adapter work in ENG-5840 and model-override ownership in ENG-5891. Visibility requires explicit P4 and P9 approval. |

The profile and job-model floor decision for future behavior is: Tied-paid jobs
are locked; customer-paid jobs may raise the model; nobody may lower a floor.
A future implementation must enforce this with server-side plan-tier checks.
This is a decided future rule, not evidence of current per-job enforcement;
ENG-4912 owns floor enforcement; ENG-5891 owns agent model-override behavior.

## Exposure and event decisions remain open

For every missing action, `callable_route` and `operation_id` are `null`,
`approved` is `false`, and scopes and events remain pending review. SDK exposure is
excluded. MCP stays hidden for all key actions. Per-job reads are visibility
candidates only and need explicit approval under P4 scope review and P9
external-provider data-flow review. A provider-choice change needs its external
data-flow notice before external clients are allowed.

`model_settings.updated` and `model_key.added`, `model_key.updated`,
`model_key.rotated`, and `model_key.removed` are proposed event names only. They
make no delivery, ordering, or payload promise. Any approved design must also
respect I-30 / ENG-5876 reconciliation, ENG-4915 and ENG-4912 model-routing
constraints, I-34 key storage, direct adapter ownership in ENG-5840, and P4/P9
review. The inactive inventory is recorded in
`docs/platform-api/proposals/ENG-5860.json`; it is not imported into an
operational baseline.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.