Introduction

Scenario: Operators in the supply-chain Command Center can triage disruptions object-by-object, but leadership wants the at-a-glance picture: a late-shipment trend and the dollar exposure tied up in at-risk inventory. You will build a Quiver analysis over the risk object sets and embed it as a live dashboard in the app.

Unit 7 adds the analytics surface to the command-center app you have been assembling. The Workshop module from Unit 6 is built for operating on one object at a time — open a DisruptionEvent, read its risk, fire the triageDisruption action. What it does not give leadership is the aggregate view: how late-shipment volume is trending over time and how much capital is exposed across at-risk inventory. Quiver is Foundry's point-and-click analysis tool for exactly this. It works directly on object and time-series data from the Ontology, and because the links between objects are natively represented, you avoid hand-writing joins to follow a DisruptionEvent to the Shipments it affects or a Shipment to its InventoryItem stock. You will build a Quiver analysis on the Shipment and DisruptionEvent object sets, then embed the resulting dashboard back into the Command Center so the analytics live where operators already work.

There is an important honesty constraint baked into how this unit is checked. A Quiver analysis and the act of embedding it into Workshop or an Object View are authoring artifacts that are not exposed by the Foundry read API — there is no endpoint that returns 'this dashboard exists' or 'this dashboard is embedded in module X'. So those two steps are self-attested, and the unit instead verifies the underlying data the dashboard must reflect. The mechanism is the Aggregate Objects endpoint, the same v2 read-API aggregation Quiver itself runs under the hood. You will reproduce the dashboard's two headline numbers independently — a count of late shipments and a sum of inventory exposure — so that a passing aggregation is the machine-checkable proxy for a dashboard that surfaces the same figures. If your Quiver headline disagrees with the aggregation, one of them is wrong.

By the end you will have a Quiver dashboard combining a late-shipment trend with exposure metrics, embedded into the Command Center app, and you will have proven the two headline metrics reconcile against the Ontology via aggregation. This completes the read/analyze half of the operator loop: Unit 5 gave you the function-backed action that edits the Ontology, Unit 6 gave you the operating surface, and Unit 7 gives leadership the aggregate signal that tells them whether the disruption response is working.

Capability focus: Quiver object/time-series analyses; embedding dashboards into Workshop/Object Views; aggregation as the machine-checkable proxy. · Artifact: A Quiver dashboard embedded into the Command Center app.

Key concepts

Companion video

1. 1

   Build the Quiver object/time-series analysis

   Open Quiver and build an analysis on the risk object sets that feed the Command Center. Start from the Shipment and DisruptionEvent object types and use Quiver's native link traversal — no manual joins — to bring in the related objects you need (for example, following Shipment to its InventoryItem stock for exposure context). Create at least two visualizations: a late-shipment trend charted over a timestamp property (shipments with status 'late' bucketed over time) and an exposure metric (the total dollar value tied up in at-risk inventory). Build these against the concrete object types, not the RiskEntity interface, since Quiver analyses operate on object sets and the interface is not a Quiver/Workshop concept. This step is self-attested: the Quiver analysis is authoring content that the Foundry read API does not expose, so no automated check can confirm the chart exists — the checks in the next two steps instead verify the data the dashboard must reflect.

   not startedself-attested

   Mark complete

   Self-attested: a Quiver analysis is built on the Shipment/DisruptionEvent object sets (content is not read-API-exposed).

2. 2

   Reproduce the dashboard's headline metric via aggregation

   Reproduce the dashboard's headline late-shipment count independently using the Aggregate Objects read-API endpoint — the same aggregation Quiver runs internally. Run a count aggregation over the Shipment object set filtered to status equal to 'late'. The result must equal the figure your Quiver headline shows; for the seeded scenario that count is 3. This aggregation is the machine-checkable proxy for the dashboard: a Quiver chart is not introspectable, but the number it must display is. If your Quiver headline and this aggregation disagree, fix the analysis (typically a wrong filter or the wrong status value) before moving on — the dashboard and the Ontology must report the same late-shipment volume.

   not startedinstance check

   Run check

   Confirms the dashboard's headline late-shipment count reproduces via an aggregation.

3. 3

   Reproduce the exposure metric via aggregation

   Reproduce the dashboard's exposure metric the same way: run a sum aggregation over the InventoryItem object set on the exposureUsd property via Aggregate Objects. The total must match the exposure figure your Quiver dashboard surfaces; for the seeded data the sum is 300000 (total exposure in dollars). As with the late-shipment count, the dashboard's own configuration is not API-introspectable, so this sum aggregation stands in as the verifiable backbone of the exposure metric. Confirm the property name and units in the Ontology match what your chart aggregates, since a dashboard that sums the wrong field or mixes units will silently disagree with this check.

   not startedinstance check

   Run check

   Confirms the exposure metric reproduces via a sum aggregation over InventoryItem.

4. 4

   Embed the dashboard in the app

   Embed the Quiver dashboard into the Command Center so the analytics live where operators already work. Add it to the Workshop module (Quiver dashboards can be embedded in Workshop) and/or to a relevant Object View, the two supported embedding surfaces. Place the late-shipment trend and exposure metrics where leadership and operators will see them alongside the existing risk list and triage action from Unit 6. This step is self-attested: the embed relationship between a Quiver dashboard and a Workshop module or Object View is authoring configuration that the Foundry read API does not expose, so no automated check can confirm it — capture the embedded view in your walkthrough evidence so a reviewer can judge placement and that the in-app figures match the aggregations you just verified.

   not startedself-attested

   Mark complete

   Self-attested: the Quiver dashboard is embedded into the Workshop module / Object View.