Introduction

Scenario: Your team is about to build a supply-chain Command Center app where operators triage disruptions and trace their blast radius across orders, shipments, inventory, and suppliers. Before any function, action, or Workshop page is built, you must confirm the Ontology the app reads is actually grounded: the right object types, the properties the operator screens depend on, and the link types that make event-to-supplier navigation possible.

This unit grounds the Ontology that the entire Command Center app suite will stand on. In Foundry, an 'object type' is the schema for a kind of real-world thing (a Supplier, a PurchaseOrder, a Shipment) defined in Ontology Manager, and the app you build over the next units will read those object types, traverse the 'link types' between them, and edit them through actions. Nothing downstream works if the backbone is missing: a Workshop object-set widget cannot list disruptions that have no object type, and a query function cannot roll up risk across orders if the Shipment-to-PurchaseOrder link does not exist. So before writing code, you confirm the five supply-chain object types (Supplier, PurchaseOrder, Shipment, InventoryItem, DisruptionEvent) are present and correctly shaped.

Two design decisions made in Ontology Manager carry through every later unit. First, each object type needs a primary key (the unique identifier that makes an instance addressable) and a title key (the human-readable label the app shows in lists and headers); these are set on the Properties step when the object type is created against a backing datasource. Second, properties are not free: the operator screens read specific named fields, so DisruptionEvent must actually expose eventType, status, owner, and severity, because the triage workflow in later units sets the owner and flips the status, and Workshop will bind widgets to severity and eventType. You are confirming the schema (the property names and types exist), not the data values.

You will close the unit with an Ontology readiness brief that maps each object type and link to the operator workflow it enables and names any gaps to fix before the build begins. This brief matters precisely because some of the most important configuration is not visible to a read API: link-type cardinality, which property is the primary key versus the title key, and which ontology (private vs shared) a type lives in are all set in Ontology Manager but are not introspectable the way object-type and property existence are. The brief is where you record those human-verified facts so the rest of the team can trust the foundation.

Capability focus: Object types + properties + primary/title keys; link types for navigation; reading the Ontology an app depends on. · Artifact: An Ontology readiness brief plus the five app object types, each with a primary key, app-required properties, and >=1 link type.

Key concepts

Companion video

1. 1

   Confirm the five app object types exist with primary keys

   Confirm the app's Ontology backbone is present: the five supply-chain object types — Supplier, PurchaseOrder, Shipment, InventoryItem, and DisruptionEvent — must each exist as an object type with a primary key. In Ontology Manager, each object type is created against a backing datasource and, on its Properties step, assigned a primary key that makes its instances uniquely addressable and linkable. The check here uses List Object Types (v2) to verify all five apiNames are present and that each returns a non-empty primary key; if any type is missing or lacks a primary key, the app has no foundation to read, so create or fix it before continuing. You are confirming the object types and their keys exist as schema, not validating any row of data.

   not startedinstance check

   Run check

   Confirms the five supply-chain object types are present, each with a primary key.

2. 2

   Confirm DisruptionEvent carries the app-required properties

   Confirm the DisruptionEvent object type carries the specific properties the operator screens read: eventType, status, owner, and severity. In later units the triage workflow sets owner and flips status, and Workshop binds widgets to severity and eventType, so these named fields must exist on the schema now. Open DisruptionEvent in Ontology Manager and verify each property is defined with an appropriate base type (and, where the workflow depends on it, the Required toggle set intentionally). The check uses Get Object Type to confirm the property names and schema exist on DisruptionEvent — it verifies existence and shape, not the values any instance holds. Resist adding properties the app will never read: property bloat makes the object type harder to reason about and slows downstream binding.

   not startedinstance check

   Run check

   Confirms the DisruptionEvent object type exposes the properties the operator app reads (by name).

3. 3

   Confirm link types are defined for navigation

   Confirm link types are defined so the app can navigate the model rather than hand-joining datasets. Supplier, PurchaseOrder, and DisruptionEvent must each expose at least one link type, enabling the operator path DisruptionEvent -> Shipment -> PurchaseOrder -> Supplier that the Command Center relies on to show a disruption's blast radius. In Ontology Manager, define link types between the relevant object types and choose the cardinality that matches reality (a PurchaseOrder having many Shipments, for example). The check uses Get Object Type metadata to confirm each of the three named object types returns at least one link type. Note an important honesty limit: the read API confirms a link type exists, but link-type cardinality (one-to-one, one-to-many, many-to-many) is configuration set in Ontology Manager and is not introspectable through the object READ API — so record the cardinality you chose in the brief rather than assuming the check verified it.

   not startedinstance check

   Run check

   Confirms Supplier, PurchaseOrder, and DisruptionEvent each have at least one link type so the app can traverse the model.

4. 4

   Write the Ontology readiness brief

   Write a one-page Ontology readiness brief — this step is self-attested because the facts it captures are not confirmable by a read API. Map each of the five object types and each link type to the specific operator workflow it enables (for example, the DisruptionEvent -> Shipment -> PurchaseOrder -> Supplier chain enables tracing a disruption back to the responsible supplier), and explicitly name any gaps to fix before the app build begins. Crucially, record the configuration the instance checks cannot see and you verified by hand in Ontology Manager: each link type's cardinality, which property is the primary key versus the title key on each object type, and which ontology the types live in (private vs shared — recall an ontology maps 1:1 to a space). The brief is the durable record the team trusts when starting the build, so be explicit about what was machine-confirmed versus human-verified.

   not startedself-attested

   Mark complete

   Self-attested: a brief maps each object type/link to the operator workflow it enables and names gaps.