Introduction

Scenario: Procurement leadership wants every supplier in the disruption-risk forecast flagged directly on its Ontology object so non-ML operators can triage the riskiest suppliers without opening a notebook. You will run batch inference over the full supplier population and land a DisruptionRisk band on each Supplier object.

Unit 5 turns the model you trained, evaluated, and analyzed in the prior units into an operational signal that lives where the business actually works: the Ontology. Until now your predictions have existed as analyst-facing tables and dashboards. The goal this unit is batch inference — scoring the entire current supplier population at once and writing the result back onto the Supplier object type — so that a procurement operator looking at a supplier in Workshop sees a DisruptionRisk band next to the supplier's other properties. This is the difference between a model that an analyst can query and a forecast the organization can act on.

The mechanics rest on three pieces of Foundry. First, Pipeline Builder's trained-model node runs your published model version against an input dataset to produce a batch-predictions dataset. Second, Pipeline Builder's Add an Ontology output capability writes transformation results — including those model predictions — onto an object type as object properties, which is how a numeric score and a derived risk band reach the Supplier objects. Third, the Ontology Aggregate Objects API lets you reproduce the risk distribution directly from object state, so you can confirm the forecast landed and quote a defensible high-risk count to leadership. This is what 'models in the Ontology' means in practice: the model's output is connected to objects via the platform, then consumed as ordinary object properties by downstream Actions and Workshop applications.

An important modeling decision shapes how this unit is checked. The batch-predictions dataset carries a numeric disruption_risk_score per supplier, but the Ontology object carries a DisruptionRisk band stored as a string (for example "high", "medium", "low"). The band is what operators triage on, what object-state checks read, and what an equality-filtered aggregation counts — the raw numeric score is a separate, finer-grained property. Keeping the human-actionable band as a discrete string property is deliberate: it is what makes the forecast legible to non-ML staff and what makes a count of high-risk suppliers a clean, reproducible number.

Capability focus: Batch inference; models in the Ontology; populating a DisruptionRisk property; reproducing the risk distribution via aggregation. · Artifact: A batch-predictions dataset and an Ontology-bound DisruptionRisk property populated on objects.

Key concepts

Companion video

1. 1

   Predictions dataset exists with score column

   Run batch inference by placing the trained-model node in Pipeline Builder, pointing it at the supplier feature input and at your published model version, and materializing the result as the model_predictions dataset. The completeness check confirms this dataset resolves by name and that its schema carries the supplier_id key and the predicted disruption_risk_score column — evidence that inference actually ran and emitted a per-supplier score, without inspecting the model itself. The check reads only the dataset's existence and column schema (Get Dataset / Get Dataset Schema); it does not and cannot verify how the score was computed, since the trained model, its ModelAdapter, and the version-to-node binding are not exposed through a read API. Make sure supplier_id is the stable join key you will later use to write back to objects, and that disruption_risk_score is the continuous numeric output — the human-facing band is derived from it in the next step, not stored here.

   not startedinstance check

   Run check

   Confirms the batch-inference output resolves with the predicted-risk column.

2. 2

   DisruptionRisk property populated on objects

   Use Pipeline Builder's Add an Ontology output to write the predictions onto the Supplier object type, deriving a discrete DisruptionRisk band (e.g. "high"/"medium"/"low") from the numeric disruption_risk_score and landing it as the disruptionRiskBand property. The check confirms object state: the Supplier object type now carries disruptionRiskBand and at least one Supplier object has it populated (a non-empty band). Store the band as a STRING — not a raw float — because that is what makes the property triageable by operators, matchable by this object-state check, and countable by the equality aggregation in the next step; you can keep the numeric score as a separate property, but the band is the operational signal. This is what 'models in the Ontology' looks like in the batch case: the model output reaches objects as ordinary properties via the platform, ready for Actions and Workshop, with no live inference call involved.

   not startedinstance check

   Run check

   Confirms the object type carries a populated DisruptionRisk band on its objects.

3. 3

   Risk distribution reproducible via aggregation

   Reproduce the risk distribution directly from object state using the Aggregate Objects v2 API: POST to the Supplier object type's aggregate endpoint with a count metric and a where filter of disruptionRiskBand equal to "high". The check confirms this returns the expected high-risk supplier count — the number you will cite to leadership — which works precisely because the band is a discrete string the equality filter can match. This step deliberately introspects the resulting object metric, not the model: it proves the forecast landed and is countable in the Ontology, not that the model is well-calibrated (that was the prior units' job). You can extend the same call with a groupBy on a supplier segment, or swap count for an avg of the numeric score, to brief leadership on where risk concentrates; the graded assertion is the high-risk count reproduced within the Ontology.

   not startedinstance check

   Run check

   Confirms the high-risk supplier count reproduces via an equality-filtered aggregation on the risk band.

4. 4

   Property semantics documented for operators

   Document the DisruptionRisk property for the operators who will act on it: what the band means, its scale and thresholds (how disruption_risk_score maps to "high"/"medium"/"low"), and how often the batch pipeline refreshes the property so a stale band is never mistaken for a live one. This step is MANUAL and self-attested — no read API can confirm that prose documentation exists or that it is accurate — so the check records your attestation rather than verifying content. Treat it with the same rigor as the graded steps anyway: a non-ML procurement operator triaging suppliers on the band must know what it represents, its refresh cadence, and its limits, or the operationalized forecast will be misread. Capture this alongside the model version and pipeline RID so the binding between the landed property and the model that produced it is traceable even though that binding is not API-introspectable.

   not startedself-attested

   Mark complete

   Self-attested: the DisruptionRisk property's meaning, scale, and refresh cadence are documented.