Introduction

Scenario: The disruption-risk model now scores suppliers in batch, but planners want to recompute a supplier's risk the instant its on-time rate or lead time changes, directly inside the Actions and Workshop screens they already use. Your job is to publish the model as a query function so on-demand disruption-risk forecasting becomes a first-class, governed capability of the Ontology.

Unit 7 closes the gap between a deployed model and the operational Ontology by turning the disruption-risk model into a published model Function: a thin query-function wrapper that takes supplier and shipment property inputs and returns a disruption-risk prediction on demand. Batch inference (Unit 5) and the live deployment (Unit 6) gave you scored objects and a queryable REST endpoint, but neither is something an Action rule or a Workshop button can call directly. Direct function publishing produces exactly that callable surface: a function that queries a direct model deployment by its stable URL and is imported and invoked like any other query function.

This matters because models become valuable to operators only when they are bound into the Ontology. The official pattern, models in the Ontology, connects a model to objects through Functions that bind object properties to model inputs and interpret model outputs as object-derived values, enabling model-backed Actions and Workshop UI. Direct function publishing is the recommended downstream path: the wrapper auto-upgrades to new model versions on its branch, so the Function planners call today keeps pointing at the latest approved model without rewiring. You will confirm the published Function exists with the right input/output signature, then prove it actually scores by executing it, because a model Function is only trustworthy if it returns a real prediction, not merely if it resolves.

Honesty about what the platform exposes is the through-line of this unit. The published Function's signature is confirmable through the Ontology read API (Get Query Type returns apiName, parameters, output, rid, and version), and its behavior is confirmable by execution (Execute Query returns the output shape). What is not API-introspectable is the wiring underneath: the direct model deployment that backs the wrapper and the resource-import / query-function registration that makes it available to Actions and Workshop are confirmed by self-attestation, not by a documented public read API. You will treat the first two steps as machine-verifiable and the last two as honest manual attestations, and you will keep the live-deployment transport (the separate foundry-ml-live POST endpoint) clearly distinct from the Ontology Execute Query path you use here.

Capability focus: Direct function publishing; model Functions (query functions); object-property inputs; downstream consumption. · Artifact: A published model Function returning a disruption-risk prediction, importable for Actions/Workshop.

Key concepts

Companion video

1. 1

   Published model Function exists with correct I/O schema

   Direct function publishing produces a query function: a typed function on the Ontology with an apiName, a parameters input schema (the supplier/shipment feature inputs), and an output schema (the disruption-risk prediction). Publish the model as a Function so this query function exists, then confirm it with Get Query Type (GET /api/v2/ontologies/{ontology}/queryTypes/{queryApiName}), which returns apiName, parameters, output, rid, and version. This step is machine-verifiable: it confirms the Function is published and enumerable with the expected I/O signature. Note that confirming the signature does not confirm the wrapper scores correctly — that is the next step. Make sure the published apiName and its feature inputs match what downstream Actions and Workshop will pass, so the contract you expose is the one consumers expect.

   not startedinstance check

   Run check

   Confirms the model Function (query function) is published and enumerable.

2. 2

   Function executes and returns a prediction (execute)

   A model Function is only trustworthy if it returns a real prediction, so confirm behavior by execution rather than by introspecting the wrapper's logic. Use Execute Query (POST /api/v2/ontologies/{ontology}/queryTypes/{apiName}/execute) against the published Function with a seeded supplier input, and confirm the response is a structured, non-empty disruption-risk result carrying the expected named output fields (the risk band/prediction plus its confidence). This is the execute-confirm pattern: you prove the wrapper actually queries its direct model deployment and produces a usable score end to end. Keep this Ontology Execute Query call mentally separate from the live deployment's foundry-ml-live POST transport from Unit 6 — they are different endpoints serving different purposes, and only this one is invoked as a query function on the Ontology.

   not startedinstance check

   Run check

   Executes the published model Function on a seeded input and confirms a structured, non-empty result.

3. 3

   Direct model deployment exists for the wrapper

   The published Function is a thin wrapper that queries a direct model deployment by its stable URL; that deployment is the runtime actually executing inference. Confirm that a running direct model deployment backs the Function and that the wrapper points at its stable URL on the intended branch, so version auto-upgrade behaves as expected. This step is a self-attestation: the existence of the direct model deployment and the wrapper's binding to it are not surfaced by any documented public read API, so there is no READ call that machine-confirms it. Record the deployment and its stable URL in your handoff notes, and verify through the application UI that the deployment is healthy and serving, since the execute step in this unit only proves the path works at the moment it was called.

   not startedself-attested

   Mark complete

   Self-attested: a running direct model deployment backs the Function wrapper.

4. 4

   Function imported for downstream use

   For Actions and Workshop to call the model Function, the query function must be registered through Resource Imports / Query Functions in the consuming application; without that import wiring the Function exists but is not reachable from the operator surfaces. Confirm that the query function has been added for downstream use so model-backed Actions and Workshop screens can invoke it on Ontology objects. This step is a self-attestation: the import/registration state is configuration that is not API-introspectable, so it is verified by inspecting the application's imports rather than by a read API. Validate the wiring by actually invoking the Function from a test Action or Workshop widget against a seeded object, so you confirm the end-to-end operator path and not just the import entry.

   not startedself-attested

   Mark complete

   Self-attested: the query function is added via Resource Imports / Query Functions for Actions/Workshop.