Models, providers, and projects
Feeds categories D1 (provider abstraction) and G1 (admin surface).
Starting state from the fast track: providers and models from the onboarding wizard already exist; 9.1 is partially carried over.
Grade each scenario Pass (2 points), Pass with gaps (1), or Fail (0) against the grading rubric, and carry the subtotal into the summary scorecard.
Scoresheet document
This page can be downloaded as PDF or printed directly. Site navigation is omitted, the scoring table keeps its rows intact with the header repeated on every page, and the Grade and Notes columns leave room for handwriting.
| ID | Scenario | Guide | Grade | Notes |
|---|---|---|---|---|
| 9.1 | Add a provider and enable or disable models from the catalog. Verify: an enabled model becomes callable and a disabled one returns a clear error. (Partially carried over from fast-track Step 1; the disabled-model error still needs verification.) | Managing models and providers | ||
| 9.2 | (optional) Provision AWS Bedrock models. Verify: a Bedrock model answers through the gateway. | Provisioning AWS Bedrock models | ||
| 9.3 | (optional) Connect provider subscriptions across clouds. Verify: the same logical model resolves to different provider subscriptions as configured. | Connect provider subscriptions across clouds | ||
| 9.4 | (optional) Provision a custom or self-hosted model behind an OpenAI-compatible endpoint. Verify: the custom model is callable through the gateway. | Provision custom and self-hosted models | ||
| 9.5 | Create a project as the isolation boundary for a team. Verify: the project owns its own models, keys, and members. | Create a project | ||
| 9.6 | Label a data plane with the project, from the data plane's Project labels panel or the Create Project wizard's Data planes step. Verify: the label shows label applied, config pulled, and verified once a request succeeds, and the Developer Console lists the data plane's address as the project's endpoint. A project with no label shows no Base URL. (Optional Enterprise HA) Labelling a second data plane that declares the same hostname is a separate check (see Serve a project from two data planes). | Serve a project from a data plane | ||
| 9.7 | Manage project Users and roles. Verify: a User sees only their project after the switcher re-scopes. | Manage project Users | ||
| 9.8 | Issue a project API key and test isolation. Verify: the key works on every endpoint serving its project and is rejected (403, category hostname_not_selected) on a hostname that does not serve it. On a data plane labelled with two projects, the key cannot call the other project's models (400 model_not_found), and GET /v1/models lists only its own project's models. | Issue a project API key | ||
| 9.9 | (optional, self-hosted) Deploy an additional data plane with its hostnames declared. Verify: the new data plane registers, the Admin Console lists the hostnames it declares, and it reads "Serving nothing, by design" until a project is labelled on it. | Deploy a data plane | ||
| 9.10 | (optional) Add and remove project labels on a data plane. Verify: labelling or removing one project does not drop another project's traffic on the same data plane, and removing a project's last label is refused unless acknowledged. | Manage a data plane's addresses and projects | ||
| 9.11 | (optional) Move a project to another data plane. Verify: the customer-facing hostname is unchanged when both data planes declare it, and in-flight requests survive the DNS shift. | Move a project to another data plane | ||
| Subtotal | /22 |