Relationship Types

The two are being made to interoperate. A statement of intent, not evidence that they interoperate.

No second name: shown the same from both sides.

The subject cites the object as foundational architecture, specification or codebase, or borrows its syntax or vocabulary.

Read from the other side: Basis for basis_for

The subject provides a translation or adapter layer that connects systems that could not otherwise interoperate.

Read from the other side: Bridged from bridged_from

The subject is implemented on the object as its primary substrate, or bundles it as an integral component. An application on a runtime (such as a Holochain hApp) is built on it.

Read from the other side: Hosts hosts

The two serve overlapping use cases as alternatives (symmetric).

Reads the same from either side; stored once.

The two are commonly used together as components, or were designed to fit; one may be optional for the other (symmetric). A brief note says which.

Reads the same from either side; stored once.

The subject is a conformant implementation of the standard.

Read from the other side: Conforming implementations has_conforming_implementation

The subject originates as a fork of the object's codebase.

Read from the other side: Forks fork_of

The subject uses the object as its identity primitive.

Read from the other side: Identity primitive for identifies_for

The subject cites the object as conceptual or design inspiration, without being a fork.

Read from the other side: Inspired inspired

The two work together in a shared flow, by design or by agreement, so that each can take part in the other's workflows; shown in practice or explicitly claimed, with the claim sourced.

Reads the same from either side; stored once.

The subject depends on the object: it cannot function without it as a runtime, a coordination, settlement or transport layer, or a function it hands over. A brief note says which.

Read from the other side: Required by required_by

The subject implements the protocol.

Read from the other side: Protocol spoken by protocol_spoken_by

The subject uses the object as its persistent data substrate.

Read from the other side: Storage for storage_for

The object is a later version or replacement of the subject.

Read from the other side: Succeeds succeeds

The subject is a generalization of the object's pattern to a broader domain.

Read from the other side: generalized by generalized_by

The subject applies the object's general pattern to a more specific domain.

Read from the other side: specialized by specialized_by

The subject marks the object as obsolete in its ecosystem.

Read from the other side: deprecated by deprecated_by

The subject uses the object as its mechanism for verifying claims, identities or credentials.

Read from the other side: verifies for verifies_for

The subject uses the object as a routing intermediary.

Read from the other side: mediator for mediator_for

The subject uses the object as its payment rail.

Read from the other side: payment for payment_for

The subject became the object's authoritative successor through a formal governance handoff (a charter transfer, a foundation donation); distinct from technical succession.

Read from the other side: governance predecessor of governance_predecessor_of

The tool is developed by the organization.

Read from the other side: develops develops

The subject receives funding from the organization.

Read from the other side: funds funds

The subject's primary code or specification lives in the organization's repository or organizational space.

Read from the other side: hosts project hosts_project

The subject has been submitted to or accepted by a standards body.

Read from the other side: standardizes standardizes

The subject is governed, stewarded or maintained by the organization.

Read from the other side: stewards stewards

An affordance belongs to a use case domain.

No second name: shown the same from both sides.

A tool provides an affordance.

No second name: shown the same from both sides.

An entity type is closest to another in the comparison of entity types.

No second name: shown the same from both sides.

The tool's entity type (its category).

No second name: shown the same from both sides.

The stack layer where the tool does most of its work.

No second name: shown the same from both sides.

The tool occupies, abstracts over or subsumes a stack layer (see spanningType).

No second name: shown the same from both sides.

The tool is a member of a suite.

Read from the other side: suite includes suite_includes

The two share the values of several descriptive attributes in the Monetary Architecture or the Organization Governance Models comparison; the note lists which. A structural resemblance, not a strength or a ranking (symmetric).

Reads the same from either side; stored once.

The two organization governance models are described as working together in coordination (symmetric).

Reads the same from either side; stored once.

The subject is a kind of the object.

Read from the other side: has subtype has_subtype

The subject creates the object as a legal person and its law applies to it.

Read from the other side: legally authorized by legally_authorized_by

The subject is working toward recognition from the object.

Read from the other side: recognition sought by recognition_sought_by

An organization governance model commonly uses this monetary mechanism; the note says how.

Read from the other side: mechanism used by mechanism_used_by

An organization governance model uses this tech tool; the note says whether it is required or commonly used, and for what capability.

Read from the other side: technology used by technology_used_by

A monetary mechanism corresponds to this tech tool in the catalog (its counterpart there).

Read from the other side: counterpart of counterpart_of