Relationship Semantics¶

33 relationship types formally defined in the UC-BoK knowledge graph. Of these, 12 are derived (computed from other edges — never stored directly).

This vocabulary defines the formal grammar of how UC-BoK entities relate. Each verb carries precise semantics: cardinality, lifecycle coupling, directionality, and transitivity.

Quick Reference¶

LC Coupling: ○ none · ◔ reference · ◑ moderate · ● strong

🔗 Structural¶

owns¶

Source has ownership or hierarchical authority over the target. Used for Domain→Capability, Business Object→Lifecycle, Actor→Role, Journey→Task. Lifecycle coupling is moderate: the target's meaning depends on the source but it may be re-assigned rather than deleted.

exposes (derived)¶

An Application exposes one or more APIs. Derived from apis[].application in catalogs/apis.yaml. Represents the surface area of an application's public contract. Inverse: null.

integrates-with (derived)¶

An Application integrates with another Application via a defined integration pattern (synchronous-api, event-driven, batch, webhook). Derived from integration-patterns[].source and integration-patterns[].target in catalogs/integration-patterns.yaml. Represents the integration topology of the Unified Commerce stack. Inverse: null.

enables (derived)¶

A Capability enables a key Unified Commerce scenario via another Capability. Enabling relationships mean the source capability is not strictly required but its absence makes the target scenario impossible or commercially incomplete. Derived from catalogs/capability-dependencies.yaml (type: enables). Inverse: null.

enhances (derived)¶

A Capability enhances another Capability — the source degrades without the target but can function at reduced quality. Enhancing relationships represent soft or optional dependencies. Derived from catalogs/capability-dependencies.yaml (type: enhances). Inverse: null.

requires_capability (derived)¶

A Scenario requires a set of Capabilities to execute end-to-end. Declares the minimum capability set that must be present and at sufficient UCMI maturity for the scenario to be operationally viable. Also used by Reference Architecture to declare required capabilities. Derived from catalogs/scenarios/*.yaml[capabilities].

orchestrates¶

A Business Process orchestrates one or more Capabilities across at least two distinct domains to deliver a complete end-to-end business outcome. This is the primary structural relationship of the Process Ontology (ONT-008). Derived directly from processes[].capabilities in catalogs/processes.yaml. A Process MUST orchestrate capabilities from ≥ 2 domains (PROC-SC-03).

📁 Membership¶

belongs_to¶

Declares that the source entity is a member of, or scoped to, the target. The source can exist independently. Deletion of target does not destroy source. Used for domain membership, aggregate context, and hierarchical containment.

scoped_by¶

Source entity is scoped to or constrained by the target. Used for Reference Architecture scoping to Domains, and Capability scoping to Reference Architectures.

⚙️ Behavioral¶

implements¶

Source (Application) provides a concrete implementation of the target (Capability or Process). An Application can implement many Capabilities; a Capability can be implemented by many Applications.

publishes¶

Source is the authoritative producer of the target Event. A Capability or Application publishes Events that represent its observable state changes. Deletion of source does not delete the Event type.

produces¶

Source (Touchpoint, Capability, Application, Process, Task) generates instances of the target Event at runtime. Broader than publishes; used when the producer is contextual rather than authoritative.

requires (transitive)¶

Source declares a dependency on the target to function correctly. Used by Applications, Reference Architectures, Processes, Roles, and Tasks to declare Capability or Service prerequisites.

supports¶

Source provides delivery infrastructure for the target. Touchpoints support Capabilities/Processes they can deliver. Applications and Services support Capabilities they partially enable.

manipulates¶

Source (Capability, Process, Service, Task) creates, reads, updates, or deletes instances of the target Business Object. Implies write access. More specific than references — source has mutation authority.

changes¶

Source triggers a state change in the target Business Object. Alias of manipulates with emphasis on state mutation. Used by Events and Processes.

emits (derived)¶

A Capability is the declared source of one or more Business Events. Derived from events[].source-capability in catalogs/events.yaml. Inverse: null (events do not back-reference their emitting capability in the graph).

triggered-by (derived)¶

A Process is triggered by a specific Business Event when its trigger type is domain-event. Derived from processes[].trigger-event in catalogs/processes.yaml. Inverse: null.

propagates_to (derived)¶

An Event propagates to a Capability that depends (via ONT-004) on the emitting Capability. Propagation strength mirrors dependency type: must-consume (invariant requires), should-consume (constraint requires), may-consume (enables or enhances). Derived from the intersection of catalogs/capability-dependencies.yaml and catalogs/events.yaml. Formal definition in specifications/007-ontology/event-propagation-rules.yaml.

🏛️ Governance¶

governs¶

Source defines the valid state machine (Lifecycle) or operational rules for the target. A Lifecycle governs its aggregate-root Business Object (1:1). A Capability may govern derived Lifecycles. Lifecycle coupling is strong: the governed object's state machine is defined by this relationship.

governed_by (derived)¶

ONT-006: Derived inverse of governs. Declares that the source Business Object is governed by the target Lifecycle, or that the source Lifecycle is governed by the target Capability. Generated from governs edges; not directly authored in catalogs.

triggers¶

Source Event causes a state transition in the target Lifecycle. The relationship is runtime-causal: an event instance triggers a specific transition. Not a design-time structural dependency.

requires_critical¶

Reference Architecture declares that the Capability or Process is a must-have (critical tier) component of the architecture. Absence of this Capability represents a blocking gap.

requires_important¶

Reference Architecture declares that the Capability or Process is a should-have (important tier). Absence represents a significant gap.

requires_standard¶

Reference Architecture declares that the Capability or Process is a nice-to-have (standard tier). Absence represents a minor gap.

includes_critical_process¶

Reference Architecture includes a Process at the critical tier.

includes_important_process¶

Reference Architecture includes a Process at the important tier.

includes_standard_process¶

Reference Architecture includes a Process at the standard tier.

🔍 Reference¶

references¶

Source uses or reads the target without owning it. A weak cross-boundary association. No lifecycle coupling: deletion of either party does not cascade to the other.

📊 Measurement¶

measures¶

Source Metric quantifies or evaluates the performance of the target Capability, Business Object, or Lifecycle. A Metric can measure multiple targets; a target can be measured by multiple Metrics.

measured_by (derived)¶

Derived inverse of Metric --measures--> target. Declares that a Capability, Business Object, or Lifecycle is quantified by the specified Metric.

↩️ Derivation¶

available_on (derived)¶

Derived inverse of Touchpoint --supports--> Capability. Declares that a Capability can be delivered through the specified Touchpoint. Generated from supports edges; not directly authored in catalogs.

featured_in (derived)¶

Derived: a catalog entity (Capability, Process, Business Object) appears as a node in the specified Reference Architecture view. Generated from requires_ and includes_ edges.

Generated from specifications/007-ontology/relationship-semantics.yaml · ONT-005