Introduction

Scenario: Operations now wants disruption-risk scored the moment a new supplier or shipment changes, not on the nightly batch cycle, so an analyst querying a single supplier can see its risk band update in real time. Your task is to stand up a running live deployment that serves the disruption-risk model behind a low-latency REST inference endpoint for on-demand scoring.

In Units 1 through 5 you framed the problem, trained and published a model asset, evaluated it under a Modeling Objective, analyzed its behavior in Contour and Quiver, and wrote batch predictions into the Ontology as a DisruptionRisk band. Batch inference is the right tool when you can afford to score everything on a schedule, but it cannot answer 'what is this one supplier's risk right now?' the instant its inputs change. This unit closes that gap by exposing the same model as a live deployment: a persistent, scalable REST endpoint that accepts a single named-field input and returns a named prediction in milliseconds.

A Modeling Objective live deployment is created from the objective, not from raw model code, and it has a hard prerequisite: there must be a release tagged Staging or Production. A release is a versioned, packaged, production-ready asset with environment tags, a version number, and release notes; the live deployment serves whatever release you have tagged. Because your model declared a multi-field input/output API through its ModelAdapter, you will use the recommended Multi I/O query type, which mirrors that ModelAdapter api() contract rather than the deprecated single-I/O tabular form. You configure replicas and CPU/GPU, and Foundry handles scaling with no-downtime updates.

Two honesty points shape how this unit is verified. First, the live endpoint is reached over a separate transport — a POST to the foundry-ml-live inference path with Bearer auth and a JSON body — not through the Ontology Execute Query API you will use for the model Function in Unit 7. This transport is exercised in preview, so when the deployment is unreachable the check returns 'blocked' rather than pass or fail. Second, there is no documented public read API that introspects a live deployment's config, health, release tags, or serving metrics. Everything you can prove programmatically here comes from executing the endpoint and inspecting the response shape; the rest — the Staging/Production tag and the scaling/health configuration — is self-attested against the Logs & Metrics tab in the product.

Capability focus: Live deployments (foundry-ml-live); on-demand inference; release tagging (Staging/Production); resource/scaling config. · Artifact: A running live deployment exposing the model behind a queryable REST inference endpoint.

Key concepts

Companion video

1. 1

   Live deployment returns a prediction (execute)

   Confirm the live deployment is actually serving inference by querying it. The check issues a POST to the foundry-ml-live inference transport — <ENVIRONMENT_URL>/foundry-ml-live/api/inference/transform/ri.foundry-ml-live.<RID>/v2 — with Bearer auth and a JSON body of named inputs (here, a single supplier such as SUP-1), and asserts the response contains the named prediction output (disruption_risk). This is execute-only confirmation: there is no read API to introspect deployment config or health, so the only way to prove the endpoint works is to call it. This transport runs in preview, so if the deployment is unreachable the step returns 'blocked' rather than pass or fail — that means the deployment could not be reached, not that your model is wrong. Make sure a release is tagged and the deployment is running before you expect this to pass.

   not startedinstance check

   Run check

   Confirms the live deployment serves inference and returns a prediction (preview → blocked if unreachable).

2. 2

   Prediction output conforms to the model API shape

   Confirm the deployed model honors its full input/output contract. The same foundry-ml-live POST is issued, but now the check asserts the response carries every expected named output field — disruption_risk and confidence — exactly as your ModelAdapter api() declared them at publish time. Because you used the Multi I/O query type, the response field names mirror the adapter contract rather than a flattened tabular row, so a missing or renamed field indicates a mismatch between the adapter you published and what the deployment is serving. As in the previous step this is asserted on the live execute response (not via introspection), and an unreachable preview deployment yields 'blocked'.

   not startedinstance check

   Run check

   Confirms the live-deployment response carries the expected named output fields.

3. 3

   Release tagged Staging/Production before deployment

   This step is self-attested because no documented public read API exposes a Modeling Objective's release or tag state (R-ML1). A live deployment can only serve a release that is tagged Staging or Production, so before deploying you must, in the Modeling Objective, package the submitted model version into a release and apply a Staging or Production tag with a version number and release notes. Record which release and tag back this deployment so a reviewer can trace the served endpoint to a specific, immutable model version. Without a tagged release the deployment cannot be created — treat this as the gating prerequisite for the two execute steps above.

   not startedself-attested

   Mark complete

   Self-attested: a release with a Staging or Production tag exists in the objective.

4. 4

   Resource/scaling config appropriate and serving healthy

   This step is self-attested because host and inference telemetry are not exposed through the documented public read APIs — they live in the Logs & Metrics tab of the live deployment. Set the deployment's resource and scaling configuration (replica count and CPU/GPU) to match the expected on-demand query load, then open Logs & Metrics to confirm the deployment is serving healthy: replicas are up, requests are succeeding, and latency is within the target for real-time scoring. Document the chosen replica/CPU/GPU settings and your basis for them so the deployment is reproducible and operators know what 'healthy' looks like for this endpoint.

   not startedself-attested

   Mark complete

   Self-attested: replica/CPU/GPU config is set and the Logs & Metrics tab confirms healthy serving.