Introduction

Scenario: The supply-chain command-center app needs a reorder recommendation it can call from anywhere, so you author it as a Python query function over InventoryItem and confirm published functions are consumable across Workshop, Quiver, and Automate.

In Unit 3 you published a TypeScript-v2 query function for the operator app; this unit builds the same muscle in Python and forces the cross-language decision that every Foundry app team eventually faces. Foundry Functions support three implementations — TypeScript v1, TypeScript v2, and Python — and all three provide first-class support for authoring logic on the Ontology: reading object properties, traversing link types, and (for edit functions) making Ontology edits. The command center already reads risk from a TS-v2 function; here you add reorderSuggestion, a Python query function over the InventoryItem object type that proposes how much of a SKU to reorder and why, so an operator triaging a disruption can act on inventory exposure without leaving the app.

A query function is the read-only subset of functions exposed through the API gateway. You create a Python functions repository from the 'Python functions template' (initialized with my_function.py), author your logic in a function decorated with @function and given an api_name, and verify it in the Functions helper Live Preview before committing. Publishing happens by tagging a version / committing, after which the function is viewable and managed in Ontology Manager's Functions tab and enumerable through the read API. Because query functions are read-only, they cannot have side effects such as modifying the Ontology — editing the Ontology is the job of an Action backed by an edit function, which is Unit 5's subject. That distinction is not a style preference: an edit function will never appear in List Query Types or run via Execute Query, so for queries like reorderSuggestion the read API is the honest, machine-checkable proof of publication and output shape.

The unit closes with the language-feature decision the app actually depends on. TypeScript v2 and Python do not have identical capabilities, and the most consequential gap for this course is that Ontology interfaces — the RiskEntity interface you defined in Unit 2 — are fully supported only in TypeScript v2 Functions and are NOT supported in TypeScript v1 or Python Functions. So a function that takes an interface parameter must be TS-v2; a straightforward read-and-aggregate like reorderSuggestion is a fine fit for Python. You will record this tradeoff as a deliberate note, because feature support is documented platform behavior, not something any read API can introspect from your instance.

Capability focus: Python functions repository (@function); publishing + Execute Query; TS-v2 vs Python feature tradeoffs. · Artifact: A published Python query function (reorderSuggestion) plus a language-feature tradeoff note.

Key concepts

Companion video

1. 1

   Scaffold and author a Python function

   Scaffold a Python functions repository via + New > Repository using the 'Python functions template', which initializes the repo with my_function.py. Author reorderSuggestion as a function decorated with @function and given an api_name, importing the InventoryItem object type from the generated Ontology API so you can read its properties (and traverse any links you need) to compute a suggested reorder quantity and a short rationale. Verify the logic interactively in the Functions helper Live Preview against a seeded InventoryItem before you commit. This step is self-attested: the repository, the @function decorator, the api_name assignment, and the source itself are not exposed by any read API, so the instance cannot confirm them — the next two steps verify the published, executable result instead.

   not startedself-attested

   Mark complete

   Self-attested: a Python function is authored (repo/decorator config and source are not API-readable).

2. 2

   Publish the Python query function

   Publish reorderSuggestion by committing / tagging a version; publishing uses semantic versioning, and the api-named query will resolve to the latest tagged version. Because reorderSuggestion is a query function — the read-only subset exposed through the API gateway — it becomes enumerable through the read API once published. The check confirms this by listing the published query types (List Query Types) and verifying that the apiName reorderSuggestion appears. Note that this is exactly why an edit function could not be validated here: an edit function performs Ontology edits, is not exposed through the query gateway, and would never show up in this list — only true query functions do.

   not startedinstance check

   Run check

   Confirms reorderSuggestion is published and enumerable.

3. 3

   Execute the Python function and validate output shape

   Run the published function to prove not just that it exists but that it returns the shape the command-center app expects. The check uses Execute Query, calling reorderSuggestion with the seeded itemId II-2, and confirms a non-empty result carrying the required keys sku, reorderQty, and rationale. Execute Query runs a query by apiName and version (defaulting to the default branch) and returns its structured output, which is the read-side, machine-checkable confirmation of a query function's contract. If a key is missing or the result is empty, fix the function's return structure and republish — Execute Query reflects whatever the latest tagged version actually returns.

   not startedinstance check

   Run check

   Executes reorderSuggestion and confirms a non-empty result with the required keys.

4. 4

   Note language-feature tradeoffs for the app

   Record a short language-feature tradeoff note for the app: which functions are TypeScript v2 versus Python, and why. The decisive constraint for this course is that Ontology interfaces — the RiskEntity interface from Unit 2 — are fully supported in TypeScript v2 Functions but NOT in TypeScript v1 or Python Functions, so any function that takes an interface parameter must be TS-v2, while a plain object-read like reorderSuggestion is a good fit for Python. This step is self-attested because feature support is documented platform behavior, not an instance property: no read API can introspect which language a function was written in or which capabilities it relies on. Anchor the note in the documented feature-support matrix rather than from memory, and tie each choice to a concrete app need.

   not startedself-attested

   Mark complete

   Self-attested: a note records which functions are TS-v2 vs Python and why (interfaces require TS-v2).