Models

Activate models available on the appliance and set per-workload model routing.

Console	Models
API	GET /v1/admin/models · POST /v1/admin/models/activate · GET /v1/admin/routing · PUT /v1/admin/routing/{workload}
Mutating?	Yes — requires it_admin or app_owner

Prerequisites

• Signed in as it_admin or app_owner
• Models already present on the appliance (Residion install / content pack). This page activates and routes; it does not document third-party model downloads.

Auditor

An auditor can list models and routing (GET) but activation and routing changes return 403 RES-ADMIN-403.

List available models

1. Open Models.
2. Confirm the model list loads (GET /v1/admin/models).

Activate a model

1. On Models, select the model to activate.
2. Run Activate (console control backed by POST /v1/admin/models/activate).
3. Wait for the console to confirm acceptance.

Verify activation

1. The selected model shows as active in the Models list.
2. Optional: GET /v1/admin/models reflects the activation.

Set per-workload routing

1. On Models, open the routing controls for the workload you need to change.
2. Choose the model that should serve that workload.
3. Save (PUT /v1/admin/routing/{workload}).

Verify routing

1. Re-open routing and confirm the workload points at the intended model (GET /v1/admin/routing).
2. Exercise the related product surface (for example the Client App) and confirm behaviour matches the new route. Do not expect published latency or throughput figures — none are documented.

If it fails

Symptom	Likely cause	Action
403 on activate / routing save	auditor session or missing mutating role	Sign in as it_admin / app_owner
Model missing from list	Not installed on this appliance	Contact Residion — model packaging is not a console self-serve download flow in these docs
Routing save appears to succeed but behaviour unchanged	Wrong workload key, or client cache	Re-check GET /v1/admin/routing; retry the client path