Introduction

Scenario: A severe supplier disruption threatens multiple high-priority orders; the analyst must brief leadership and demonstrate a working response workflow.

Day 10 is the capstone: you bring together everything from the prior nine days into a single, working response to a severe supplier disruption that is threatening multiple high-priority orders. AIP is the platform layer that connects AI to your data and operations to drive automation across operational processes, and today you prove you can drive it end to end. You will investigate exposure, verify the Ontology that all of this rests on, trigger a triage Action, run a published recommendation function, and package a leadership-ready briefing.

The reason this matters to the disruption-response problem is that leadership does not want raw datasets; they want a defensible answer to "which orders are at risk, what are we doing about it, and is it working?" Each capability you have learned maps to one piece of that answer. AIP Analyst lets you interrogate the situation in natural language grounded in object types and properties; the Ontology gives every order, supplier, and shipment a shared, real-world meaning; Action types let you commit standardized, governed changes; and AIP Logic functions let an LLM-backed workflow reason over the Ontology and propose the next best move.

Treat today as a dress rehearsal for a real briefing. The deliverable is not just a working pipeline but a coherent narrative that a non-analyst executive can follow, backed by live Foundry artifacts they could click into and trust.

Capability focus: AIP Analyst + AIP Chatbot + AIP Logic + Workshop + Ontology · Artifact: End-to-end demo and handoff package

Key concepts

Companion video

1. 1

   Investigate exposure with AIP Analyst

   AIP Analyst, a generally available AIP application surfaced through its Workshop widget, brings AI-powered analysis directly into your disruption-response module so you can interrogate the situation in natural language grounded in the Ontology rather than writing queries by hand. Open the AIP Analyst widget you configured earlier and ask it to identify which high-priority orders depend on the disrupted supplier and to quantify the exposure (counts, value, and at-risk delivery dates). Because the widget's analysis configuration controls data access and tool availability, confirm it is scoped to the right object set so its answers are anchored to live order, supplier, and shipment objects. Capture the resulting exposure summary as the opening fact base for your leadership brief.

   not startedinstance check

   Run check

   Confirms the capstone's exposure figure reproduces via an aggregation.

2. 2

   Confirm the Ontology backbone is in place

   Everything you are about to demonstrate rests on the Ontology, the shared model of object types, properties, and links that gives orders, suppliers, and shipments a common real-world meaning across every Foundry application. Verify that the relevant object types carry the properties your analysis and actions depend on (for example order priority, status, supplier link, and promised date) and that the order-to-supplier-to-shipment links resolve correctly. This matters because AIP Analyst grounds its answers in these object types and Action edits commit straight into them, so a missing link or stale property would corrupt the whole workflow. Spot-check a couple of at-risk orders in the object views to prove the backbone holds.

   not startedinstance check

   Run check

   Confirms all five object types exist with primary keys.

3. 3

   Demonstrate an applied triage Action

   An Action type is a single transaction that changes the properties of one or more objects through user-defined logic, built from parameters, rules, submission criteria, and side effects, with edits committing to the Ontology immediately and appearing across all applications. Run your triage Action on a flagged order, supplying parameters such as a new triage status, priority, or reassigned supplier, and let the rules update the linked objects accordingly. Point out the submission criteria that restrict who can triage and the side effects, such as a notification to the affected account owner or a scheduled build, that fire on submission. This shows leadership that the response is not a spreadsheet edit but a governed, auditable change to the system of record.

   not startedinstance check

   Run check

   Confirms a disruption was triaged (owner + status) via object state.

4. 4

   Run the published recommendation function

   AIP Logic functions are LLM-powered workflows of inputs, blocks, and outputs that reason over the Ontology, and they must be published before they can be operationalized in an application. Invoke your published recommendation function on an at-risk order so its Use LLM and Ontology-aware blocks weigh alternatives (alternate supplier, expedite, or partial fulfillment) and return a ranked recommendation. Emphasize that because the function is published it can be reached the way you have wired it, whether backed by an Action, called from another function via the Ontology function tool, or exercised from the Uses tab, and that any Ontology edits it proposes via an Apply actions tool only execute when run through an Action or Automation rather than during testing. Record the recommendation and its reasoning for the brief.

   not startedinstance check

   Run check

   Executes the recommendation function and confirms a schema-valid result.

5. 5

   Assemble the handoff package

   Close the loop by composing the leadership brief from the live artifacts you just produced: the AIP Analyst exposure summary, the verified Ontology view of at-risk orders, the committed triage Action with its audit trail, and the function's ranked recommendation. Stage these together in your Workshop module, using AIP Generated Content or Markdown surfaces alongside the analysis so the narrative reads as one coherent command center an executive can follow. Make sure every claim links back to a clickable object or action so leadership can trust and drill into the underlying data. Keep all of these resources organized within the Project so the package is shareable, reproducible, and ready to hand off after the briefing.

   not startedself-attested

   Mark complete

   Self-attested: the handoff includes support notes, risks, and caveats.