Skip to content
Agile Defense

Curriculum / AI Engineer — AIP Builder

INTERMEDIATEUnit 2unit-02

Make the recommendation reliable: multi-block Logic with Ontology tools

not started~300 min
Expand the function with a Query objects tool over Shipment/Supplier, an exposure calculation, and a Conditional that branches recommendation severity.

Introduction

Scenario: The distribution team has a first draft of the Disruption Copilot, but its recommendations read like confident guesses — they ignore how many shipments are actually at risk behind a flagged supplier. Your job is to make the recommendation reliable by grounding it in the Ontology and computing exposure deterministically before the LLM ever decides a severity.

In Unit 1 you built recommendDisruptionResponse as a single Use LLM block: a prompt over a DisruptionEvent that returns a structured recommendation. That gets you a fluent answer, but not a trustworthy one — the model is reasoning from the words in the prompt, not from the live state of the supply chain. This unit turns that single block into a composed AIP Logic function. AIP Logic is a no-code environment for building, testing, and releasing LLM-powered functions, and its power comes from block types: a Use LLM block, plus Create variable, Conditionals, Loops, Execute function, and Apply action blocks that you wire together into deterministic flow around the model.

The reliability comes from two moves. First, you ground the Use LLM block in the Ontology with its tools — Query objects, Call function, Apply actions, and Calculator. The Query objects tool lets the model read the disruption's related Shipment and Supplier objects instead of trusting prose, and you scope it to only the properties it needs (shipment status, supplier risk) so the LLM sees the least it requires. Second, you compute exposure deterministically: a Calculator or Create variable block derives a hard number — for example, the count of late shipments linked to the disrupted supplier — outside the model, so the figure that drives severity is arithmetic, not generation. A Conditional block then branches the recommendation on that exposure variable, so 'high severity' is a defensible threshold rather than a hunch.

A core honesty principle runs through this unit: very little of what you build inside Logic is inspectable from outside. No READ API exposes a Logic function's blocks, its prompt text, its output schema, or how its tools are wired — and while the function remains saved-but-unpublished, it has no queryApiName and cannot be addressed by the Execute Query API at all. So the checks here verify the Ontology substrate your composition stands on, not the composition itself: that Shipment and Supplier exist with the keys the Query objects tool binds to, that your exposure number reproduces against live objects via an aggregation, and that the DisruptionEvent links you traverse are actually present. The Conditional and tool-scoping work is self-attested, and that is stated plainly rather than dressed up as a passing test.

Capability focus: AIP Logic blocks (Query objects tool, Calculator/Create-variable, Conditional); grounding the LLM in Ontology data. · Artifact: An expanded Logic function with a Query objects tool, an exposure variable, and a severity-branching Conditional.

Key concepts

  • AIP Logic blocks: AIP Logic functions are composed from block types — Use LLM, Create variable, Conditionals, Loops, Execute function, and Apply action. You arrange these to wrap deterministic control flow (branching, variables, function calls) around the LLM rather than relying on a single prompt for everything.
  • Use LLM block and its tools: The Use LLM block consists of a prompt, tools, and an output. Its Ontology-driven tools are Query objects, Call function, Apply actions, and Calculator — these let the model read Ontology objects, invoke other functions or existing Logic functions, apply Actions, and compute, so its reasoning is grounded in real data instead of prompt text alone.
  • Query objects tool and least privilege: The Query objects tool exposes Ontology object types and properties to the Use LLM block. Scoping it to only the object types and properties the task requires (e.g. Shipment status, Supplier risk) keeps the LLM's reach minimal and the function easier to reason about and govern.
  • Deterministic exposure via Calculator / Create variable: Rather than asking the LLM to estimate magnitude, a Calculator or Create variable block computes exposure outside the model — for instance, the count of late Shipments linked to the disrupted Supplier — producing a stable number you can verify by aggregation and feed into a branch.
  • Conditional branching: A Conditional block routes the function down different paths based on a value such as the exposure variable, so recommendation severity follows an explicit, reviewable threshold instead of being generated freely by the model.
  • Inspection limits (R-VAL1): No READ API inspects a Logic function's blocks, prompt, output schema, or tool wiring; a saved-but-unpublished Logic function has no queryApiName and is not addressable by Execute Query. Reliability of the composition is demonstrated in the Logic Run panel and validated indirectly through the Ontology data it depends on.

Companion video

Tool Use in AIP Logic: Object Queries · open on YouTube

Hands-on activity

each step validates · the unit completes when all steps pass
  1. 1

    Related object types for the Query objects tool exist with primary keys

    Before the Use LLM block can read live supply-chain state, the object types its Query objects tool binds to must exist with primary keys. This check confirms Shipment and Supplier are present in the Ontology with the keys the tool relies on. In the AIP Logic editor, add a Query objects tool to your Use LLM block and point it at Shipment and Supplier, scoping it to only the properties the recommendation needs — shipment status and supplier risk — so the model reads the disruption's related objects directly rather than inferring them from prompt prose.

    not startedinstance check

    Confirms Shipment and Supplier exist with primary keys for the Query objects tool.

  2. 2

    Exposure metric reproduces against live objects

    Exposure is the number that should drive severity, so it must be computed deterministically, not generated by the model. Add a Calculator or Create variable block that derives the exposure figure — here, the count of late Shipments linked to the disrupted Supplier — and store it in a variable the rest of the function can reference. This check reproduces that figure by aggregating live objects (count of Shipments where status is late), expecting the same value your block computes. The aggregate is what is verifiable: the block's internal arithmetic is not API-readable, so the metric reproducing against the Ontology is the evidence that your exposure calculation is sound.

    not startedinstance check

    Confirms the exposure figure the Calculator/Create-variable block computes reproduces via an aggregation.

  3. 3

    Conditional branching and tool wiring

    With exposure in a variable, add a Conditional block that branches recommendation severity on it — for example, escalating severity once the count of at-risk linked shipments crosses a threshold — so the severity is an explicit, reviewable decision rather than a free-form model judgment. Keep the Query objects tool scoped to least privilege at the same time, exposing only the properties the branch and the prompt actually use. This step is self-attested: no READ API inspects a Logic function's block composition, its Conditional logic, or how its tools are scoped (R-VAL1). Verify the branching behaves correctly in the Logic Run panel against sample DisruptionEvents, and document the threshold you chose so a reviewer can judge it.

    not startedself-attested

    Self-attested: a Conditional branches on the exposure variable and the Query objects tool is scoped to needed properties.

  4. 4

    Linked objects exist to traverse

    The Query objects tool can only traverse relationships that actually exist in the Ontology, so this check confirms DisruptionEvent has at least one link type connecting it to the Shipment/Supplier objects the tool reads. Seed a DisruptionEvent that is genuinely linked to the disrupted Supplier and its late Shipments, then confirm from the Logic Run panel that the Query objects tool returns those linked instances. Running against seeded, linked instances avoids empty-ontology false-fails and proves the relationships the function relies on are present, not just the object types in isolation.

    not startedinstance check

    Confirms DisruptionEvent has at least one link type (to Shipment/Supplier) the Query objects tool relies on.