Introduction

Scenario: A supplier fire and a port backlog have thrown the supply chain into disruption, and the operations desk needs fast, defensible response recommendations instead of analysts manually triaging each event. Your job in this unit is to frame that governed decision as a single AIP Logic function that reasons over a DisruptionEvent and proposes a response.

AIP Logic is a no-code development environment for building, testing, and releasing functions that are powered by large language models. A Logic function accepts inputs — Ontology objects such as a DisruptionEvent, or plain text — and returns objects, strings, or Ontology edits, which is what lets the same function later back an Action, power a Workshop module, or be called from another function. In this unit you build the first version of recommendDisruptionResponse: a function that takes one DisruptionEvent and returns a structured recommendation. You will keep it deliberately small — a single Use LLM block — so the focus stays on framing the decision and grounding it in the disruption Ontology rather than on orchestration.

The Use LLM block is the heart of an AIP Logic function. It is composed of three parts: a prompt, tools, and an output. The prompt is where you describe the disruption-response task and reference the input object's context; the output is where you declare the shape you want back so downstream consumers receive a predictable result rather than free text. Tools — Query objects, Call function, Apply actions, and Calculator — let the model pull live Ontology data or invoke other logic, but you do not need them yet; this unit establishes the prompt-plus-output backbone and identifies the object types a future Query objects tool would bind to. Binding a real Ontology object type as the input, rather than passing loose text, is what makes the recommendation traceable back to a specific, governed record.

A critical reality to internalize early: at this stage you only save the function, you do not publish it. That distinction is not cosmetic. A pre-publish Logic function has no queryApiName and is therefore not addressable by the Execute Query API — you cannot confirm its behavior through any platform read API, only through the in-product Run panel. Likewise, the internals of a Logic function — its blocks, the prompt text, the configured tools, and the output schema — are not inspectable through any documented read API. So while you will prove that the Ontology object types your function binds to genuinely exist, the configuration of the Use LLM block itself is verified by you, by hand, in the Logic editor. Knowing the difference between what the platform can attest and what only you can attest is the first governance lesson of this course.

Capability focus: AIP Logic functions; the Use LLM block; binding an Ontology object type as input; defined output shape. · Artifact: A saved (unpublished) AIP Logic function with a single Use LLM block producing a structured recommendation.

Key concepts

Companion video

1. 1

   Logic function input is the DisruptionEvent object type

   Begin by establishing the input the function reasons over. In AIP Logic, a function accepts Ontology objects or text as input; here the input is a DisruptionEvent object so every recommendation is anchored to a specific, governed record rather than free-floating text. This check uses the Ontology read API (List Object Types) to confirm that an object type with the apiName DisruptionEvent exists with a primary key — proving the input your Logic function binds to is real. Note the boundary precisely: this confirms only the Ontology input the function references, not anything about the function itself, because a Logic function's internals are not exposed by any read API. In the Logic editor, create the recommendDisruptionResponse function and declare its input as a DisruptionEvent object.

   not startedinstance check

   Run check

   Confirms the Ontology input the Logic function binds to exists (DisruptionEvent with a primary key).

2. 2

   Use LLM block configured with a prompt and a defined output shape

   Now configure the function's core: exactly one Use LLM block, which is composed of a prompt, tools, and an output. Write a prompt that frames the disruption-response task and references the DisruptionEvent context (for example, its disruption type, affected supplier or shipment, and reported impact), and define an output shape — a structured recommendation with fields such as a recommended action, a rationale, and a confidence level — so downstream consumers receive predictable, parseable results instead of free text. Leave the tools empty for now; grounding the model in live Ontology data comes in the next unit. This step is self-attested: no documented read API inspects a Logic function's blocks, prompt text, or output schema, so you confirm the single-Use-LLM-block configuration by hand in the Logic editor.

   not startedself-attested

   Mark complete

   Self-attested: the function has one Use LLM block with a disruption-context prompt and a defined output shape.

3. 3

   Function produces a sample recommendation in the Run panel

   Validate the function end to end using the Logic Run panel, which executes the saved function in-product on a sample input. Pick a representative DisruptionEvent and run it, then confirm the model returns a recommendation that matches the output shape you defined — a concrete action, a rationale grounded in the event's context, and a confidence value. This is an honest checkpoint, not a platform-confirmed instance check: because the function is only saved and not yet published, it has no queryApiName and is therefore not addressable by the Execute Query API. There is no read API that can attest this run; you verify it yourself in the Run panel. If the output is malformed or the rationale ignores the input context, refine the prompt or the output shape before moving on.

   not startedself-attested

   Mark complete

   Self-attested: running the saved (unpublished) function on a sample DisruptionEvent yields a recommendation.

4. 4

   Disruption context object types are queryable

   Finally, identify the disruption-context object types that a future Query objects tool will ground the model in. Even though this unit's function uses no tools yet, the next unit adds a Query objects tool to pull live data, and that tool needs real object types to bind to. This check uses the Ontology read API to confirm that Supplier, Shipment, and PurchaseOrder each exist with a primary key — an existence-only confirmation, not a statement about how the function uses them. Review these object types in the Ontology and note the properties (such as a supplier's risk rating, a shipment's status and dates, and a purchase order's value) that a grounded recommendation would later draw on, so the foundation is in place for the multi-block, Ontology-grounded version that follows.

   not startedinstance check

   Run check

   Confirms Supplier, Shipment, and PurchaseOrder exist (each with a primary key) for the Query objects tool to bind to.