Introduction

Scenario: The supply-chain command-center app must show one ranked 'risk' list that mixes late Shipments and open DisruptionEvents, yet each of those is a different object type. You shape a RiskEntity interface so the app can treat heterogeneous risk-bearing objects uniformly, then decide whether this ontology work belongs in your private ontology or a shared one.

In Unit 1 you confirmed the five concrete object types the operator app reads. The command center now needs to present a single, unified risk view, but the things that carry risk are not one type: a Shipment running late and a DisruptionEvent that is still open are distinct object types with distinct backing data. Hard-coding the app against each type separately is brittle and does not scale as new risk-bearing types appear. The Ontology's answer is an interface: an abstract type that describes a shared shape (a set of interface properties) and capabilities, which concrete object types then implement. In this unit you define a RiskEntity interface with interface properties such as riskScore and status, and you make Shipment and DisruptionEvent implement it so downstream functions and OSDK code can reason over 'anything that is a RiskEntity' instead of enumerating types by hand.

An interface is not backed by a dataset and cannot be instantiated on its own; it only has meaning through the concrete object types that satisfy its constraints. An object type implements an interface when its properties (and any required links and action types) satisfy what the interface declares. This is also where current platform limits bite, and you must internalize them now because they shape every later unit: interfaces are fully supported in Ontology Manager, in TypeScript v2 Functions, and in the Ontology SDK (OSDK), but they are NOT supported in Workshop and NOT supported in TypeScript v1 or Python Functions. That means the Unit 6 Workshop app cannot bind a widget to RiskEntity; it must bind to the implementing object types (Shipment, DisruptionEvent) directly. The interface earns its keep in code (TS-v2 functions, OSDK), not on the Workshop canvas.

The second half of the unit is a placement decision. Every ontology maps one-to-one to a Space. A private ontology is private to a single organization and contains only that org's resources; a shared ontology lets multiple organizations collaborate and is automatically created with a shared Space. For a single-team command center the private ontology is usually correct; you move to a shared ontology only when other organizations must build on the same types. You will write a one-page note that records the choice and its justification. Throughout, be honest about what the platform can and cannot prove back to you: the interface-implementation relationship and the ontology-to-Space placement are configuration that the object read API does not expose, so some checks here are preview-grade or self-attested rather than hard-verified.

Capability focus: Ontology interfaces (interface properties, implementedBy); private vs shared ontology (1:1 with a Space). · Artifact: A RiskEntity interface implemented by >=2 object types, plus a private-vs-shared placement decision.

Key concepts

Companion video

1. 1

   Define the RiskEntity interface with interface properties

   Create the RiskEntity interface in Ontology Manager and give it interface properties that capture the shared risk shape every risk-bearing type must expose, for example a numeric riskScore and a status. Remember an interface is abstract: it has no backing dataset and is never instantiated on its own; it only becomes useful once concrete types implement it. Be clear-eyed about verification here. This check is PREVIEW-grade: an Ontology Interfaces API surface exists in the v2 API, but the platform's current read adapter has no confirmed interface-listing method, so the check may return 'blocked' against a live instance rather than silently passing. A 'blocked' result is honest signal that the interface presence could not be machine-confirmed, not a failure of your work; you confirm the interface visually in Ontology Manager and treat this step as preview/attested until the adapter exposes a List/Get Interface Types call.

   not startedinstance check

   Run check

   Confirms the RiskEntity interface is present in the Ontology's interface types (preview → blocked if unavailable).

2. 2

   Implement RiskEntity on two object types

   Make RiskEntity real by having two concrete object types implement it: Shipment and DisruptionEvent. An object type implements an interface when its properties (and any required links and action types) satisfy the interface's constraints, so confirm that each type exposes properties that map onto riskScore and status. This check confirms only that the two implementing object types exist with primary keys, via List/Get Object Type. That is deliberate: the v2 read API can enumerate object types and their schema, but the interface-implementation relationship itself needs a List/Get Interface Types call the adapter does not yet expose. So existence and schema of Shipment and DisruptionEvent are verified, while the 'implements RiskEntity' linkage remains preview/attested from Step 1. Note also that interfaces are usable from TS-v2 Functions and OSDK but not from Workshop, so in later units the app widgets will bind to these two object types, not to the interface.

   not startedinstance check

   Run check

   Confirms the two implementing object types (Shipment, DisruptionEvent) exist with primary keys.

3. 3

   Confirm interface-backed objects carry queryable risk data

   Prove the implementing types actually carry queryable risk data, which is what makes the abstraction worthwhile. Run an Aggregate Objects count over Shipment filtered to status equal to 'late'; the check expects this to return the seeded figure of three late shipments. This aggregation is the machine-checkable proxy for the interface's value: it does not confirm the interface relationship (that is not read-API-exposed), but it does confirm that the data the interface abstracts over is present, filterable, and countable through the v2 read API. If the count matches, you have evidence that RiskEntity is backed by genuine risk-bearing objects rather than empty types, and that a later risk-list page or function-backed variable can drive off the same query.

   not startedinstance check

   Run check

   Confirms an aggregation over the implementing types reproduces the expected late-shipment figure.

4. 4

   Decide private vs shared ontology placement

   Write a one-page placement note deciding whether this ontology work stays in your private (single-org) ontology or moves to a shared ontology. Anchor the decision in the rule that an ontology maps 1:1 to a Space: a private ontology holds only one organization's resources, while a shared ontology is created with a shared Space to let multiple organizations collaborate. For a single-team command center the private ontology is the usual choice; justify moving to shared only if other organizations must build on RiskEntity and the implementing types. This step is self-attested by design: no object read API reports which ontology or Space a type lives in, so the placement and its 1:1 Space mapping cannot be confirmed by a check. The deliverable is the reasoned note itself, naming the choice, the orgs in scope, and the consequence for collaboration.

   not startedself-attested

   Mark complete

   Self-attested: a placement note states private (single-org) vs shared ontology, with justification.