Introduction

Scenario: The command center needs repeatable recommendation logic that supports human review without ad hoc prompts.

Day 9 moves the command center from ad hoc chat prompts to a governed, repeatable recommendation engine built in AIP Logic. AIP Logic is a no-code development environment for building, testing, and releasing functions powered by LLMs: a Logic function accepts inputs such as Ontology objects or text, runs them through a sequence of blocks, and returns a structured output, an object, a string, or staged Ontology edits. For a disruption-response problem this matters because every recommendation must be reproducible and reviewable rather than depending on whatever an analyst happened to type into a chatbot.

The core of a Logic function is the Use LLM block, which combines a natural-language prompt with tools and a defined output structure, composed alongside deterministic blocks like Apply Action, Execute Function, Conditionals, and Loops. Because an LLM only has access to what you specifically provide, you ground the recommendation in curated supplier, shipment, and inventory objects from the Ontology rather than the model's open-ended guesses. Crucially, the function does not silently change data: Ontology edits can be automatically applied or staged for human review, which is exactly the supervised posture the command center needs when reallocating scarce inventory.

Finally, because LLMs are inherently unpredictable, you validate the function with AIP Evals before trusting it in production. Evaluation suites bundle test cases (input-output pairs), evaluation functions that grade how close actual output is to expected, and metrics that let you compare versions and models. Today you will define inputs and output shape, build prompt and Use LLM blocks with guardrails, publish the function, and execute it on a seeded disruption case to verify it behaves as designed.

Capability focus: AIP Logic — blocks, Use LLM, tools, evals, publishing · Artifact: LLM-backed recommendation function

Key concepts

Companion video

1. 1

   Define inputs and expected output structure

   Open a new Logic file inside your project's folder and use the Inputs panel to declare the function's parameters, for example a disrupted Shipment or Supplier object plus a text field for the disruption type. Then in the Outputs area define the final output shape the command center expects, such as a structured recommendation with a ranked alternate supplier, a reroute action, and a justification string. Defining the output structure up front, rather than letting the model free-form, is what makes the recommendation consumable downstream and comparable across cases. Keep the output schema tight so every disruption produces the same fields for reviewers.

   not startedself-attested

   Mark complete

   Self-attested: inputs and output schema are explicit.

2. 2

   Build prompt and Use-LLM blocks with guardrails

   Add a Use LLM block and write the prompt leading with the task overview (recommend a mitigation for the disrupted shipment), then the data, then tool guidance, since an LLM only has access to what you specifically provide. Guardrail the model by attaching scoped data tools like Query Objects so it can only read curated supplier, inventory, and lead-time objects from the Ontology, and bind the block to your defined output structure so it must return the recommendation in the agreed shape. Add Conditionals to branch on severity and ensure each branch returns the same output type, and prefer an Apply Action block for any deterministic Ontology change so the LLM proposes rather than directly mutates. This keeps the recommendation grounded, scoped, and auditable instead of an open-ended prompt.

   not startedself-attested

   Mark complete

   Self-attested: the prompt includes guardrails and business criteria.

3. 3

   Publish the recommendation function

   Before publishing, run the Logic on a sample input and use the Debugger to inspect the LLM's chain-of-thought and each block's execution so you can confirm the reasoning and output are sound. When the behavior is correct, use Publish to finalize the function for production use; remember that any Ontology edits only take effect once the function is wired into an action or automation, so publishing supports the human-review posture the command center requires. A published function can then back Workshop actions, power Markdown widgets when it returns strings, or be called from other functions. Publish a stable version so reviewers and evals all reference the same logic.

   not startedinstance check

   Run check

   Confirms the recommendMitigation function is published and enumerable.

4. 4

   Execute on a seeded case and check the output

   Run the published function against a seeded disruption case, for example a known port closure affecting a specific supplier, and verify the structured output matches the schema you defined and that any edits are staged for human review rather than auto-applied. To make this repeatable, capture the case in an AIP Evals evaluation suite by adding it as a test case (the seeded input plus the expected recommendation) and an evaluation function that grades how closely the actual output matches. Review the resulting metrics to confirm the function performs as designed, and use the suite to compare versions or models as you iterate. This turns a single check into a durable regression test that defends the recommendation logic over time.

   not startedinstance check

   Run check

   Executes the function on a seeded disruption and confirms a structured recommendation/rationale/confidence/suggested action.