Introduction

Scenario: A supplier fire knocks out a tier-1 plant, and the on-call operator opens your Command Center app to handle it: they open the disruption, run the analysis, triage it with one click, and the app hands back a structured next step — all on the one Ontology the prior units built.

This capstone proves the whole app suite operates end-to-end on a single Ontology rather than as seven disconnected exercises. The seven prior units each produced one layer — five supply-chain object types with primary and title keys, a RiskEntity interface, TypeScript-v2 and Python query functions, an Ontology-edit function wired into the triageDisruption function-backed Action, the Workshop Command Center module, and an embedded Quiver dashboard. Here you assemble them into the operator loop the scenario demands: open a DisruptionEvent, analyze its risk, triage it through the function-backed Action, and read back a structured recommendation from a published query function. The artifact is a working Command Center where open → analyze → triage → recommend runs as one coherent workflow.

Two facts about Foundry's read APIs shape how this unit is graded, and you should internalize them rather than work around them. First, query functions are the read-only subset of Functions exposed through the API gateway; they cannot have side effects, so the Ontology-edit function behind triageDisruption is deliberately NOT a query — it will never appear in List Query Types and cannot be run with Execute Query. The only honest proof that the edit ran is the object-state it leaves behind: a DisruptionEvent that now carries an owner and a triaged status. Second, the recommendation function (shipmentRiskRollup) IS a published query, so Execute Query can run it on the seeded capstone disruption and confirm a schema-valid, non-empty result. The capstone checks bind to exactly these surfaces — List Object Types, List Objects, and Execute Query — and nothing else.

Be clear-eyed about what the automated checks can and cannot see. They confirm the Ontology backbone exists, that a triage actually landed on an object, and that the published function returns the right shape — the load-bearing, machine-verifiable spine of the app. They cannot see the Workshop page wiring, the Button Group that fires the action, the Quiver embed, or whether the operator experience is coherent and fast. Those are real and required, but they are human-judged. The final step is therefore a recorded walkthrough: the deliverable is a Command Center where a human watches open → analyze → triage → recommend happen live, against the same Ontology the instance checks just validated.

Capability focus: End-to-end app suite over one Ontology: object types + interface + functions + function-backed action + Workshop + Quiver. · Artifact: A working Command Center app suite demonstrating open→analyze→triage→recommend.

Key concepts

Companion video

1. 1

   Confirm the Ontology + app-suite backbone exists

   Confirm the app's Ontology backbone is intact before judging anything downstream: the capstone fails fast if the model the whole suite reads is missing. This check binds to List Object Types / Get Object Type and asserts that all five supply-chain object types — Supplier, PurchaseOrder, Shipment, InventoryItem, and DisruptionEvent — exist with primary keys, exactly the spine the prior units stood up. It does not re-validate title keys, link cardinality, the RiskEntity interface, or which ontology the types live in (those are config the object read APIs do not expose); it only proves the named object types and their primary keys are present so the operator app has real types to open, filter, and act on.

   not startedinstance check

   Run check

   Confirms the five object types exist with primary keys (the app's Ontology backbone).

2. 2

   Prove the action's operational effect

   Prove the operator's triage actually changed the world, which is the only honest way to confirm an Ontology-edit function ran. The triageDisruption Action is function-backed: it calls an edit function that is NOT a query, so it will never show up in List Query Types and you cannot Execute Query it — the proof is the object-state it leaves behind. This check reads back via List Objects and asserts at least one DisruptionEvent now has a non-empty owner and a status in {assigned, resolved}, demonstrating that the edit landed through the app rather than being faked. Make sure the capstone disruption was triaged through the Command Center's Button Group (not edited by hand) so the state you see is the genuine end of the open → triage path.

   not startedinstance check

   Run check

   Confirms the capstone disruption was triaged (owner set + status assigned/resolved) via object state.

3. 3

   Prove the recommendation function runs in-suite

   Show the recommendation half of the loop runs in-suite by executing the published query function on the seeded capstone disruption. Unlike the edit function, shipmentRiskRollup is a read-only query exposed through the API gateway, so Execute Query can invoke it by apiName (using the latest tagged version) with params { disruptionId: "DISR-CAP-1" }. The check asserts the result is non-empty and schema-valid — carrying riskScore, exposedOrders, and summary — which is the structured next step the operator sees after triage. This confirms the same published function that powers the in-app function-backed Workshop variable also returns a defensible, well-shaped result on the seeded case, closing the analyze → recommend portion of the workflow.

   not startedinstance check

   Run check

   Executes the published risk/recommendation function on the seeded capstone disruption and confirms a schema-valid result.

4. 4

   Run the end-to-end operator walkthrough

   Record the end-to-end operator walkthrough, because the parts the read APIs cannot see are exactly the parts that make this an app rather than a pile of artifacts. No read API exposes the Workshop page layout, the object-set and function-backed-variable bindings, the Button Group that fires triageDisruption, or the embedded Quiver dashboard — and interfaces are not supported in Workshop, so confirm your widgets bind to Shipment / DisruptionEvent, not to RiskEntity. Capture a short recording (target under five minutes) showing one continuous run: open a DisruptionEvent on the risk-list page, view its analysis (Quiver trend plus the function-backed risk variable), click triage via the Button Group, and watch the recommendation update. The narrative coherence, speed, and whether it reads as a real operator experience are human-judged; this step is self-attested because there is no API that can verify the live workflow for you.

   not startedself-attested

   Mark complete

   Self-attested: a recorded walkthrough shows open→analyze→triage→recommend in under five minutes.