Other tools treat items as flat. We don’t.

Jira has epics and stories. PPM suites have portfolios and projects. These are containment hierarchies — not decision-relevant semantic graphs.

Priorities.ai maintains a typed, mutation-governed, auditable relationship graph on every item. Seven relationship types. Seven distinct semantics. Not one overloaded “link” field that means whatever you need it to mean today.

Why the graph matters for prioritization

When you select an initiative for commitment, you need to know:

Are there other items that must be selected with it (Bloc)?
Are there items it cannot be legitimately committed without (hard Dependency)?
Are there child items whose dependencies surface when the parent is committed (Aggregation)?
Is there an alternative approach that must be selected before the commitment is complete (Elaboration)?

A flat list of ranked items cannot answer these questions. The relationship graph is what makes a ranked list safe to act on.

The seven types

Cluster — identity / near-identity

Two items that may express the same underlying need.

Subtype	Meaning
`duplicate`	Items materially express the same request. Only one should proceed as an independent prioritization object.
`variant`	Items share a common core but differ in a way worth preserving.

Cluster resolution is Gate 1. An item’s identity must be resolved before any other relationship type can be evaluated for that item. You cannot declare a Bloc or evaluate a Dependency on an item with an unresolved Cluster candidate.

Cluster relationships can be declared by a human or surfaced as emergent candidates by the system. System-surfaced candidates carry no enforcement weight until confirmed.

A lightweight, human-declared connection indicating that two or more items are worth considering together.

Related has no enforcement weight. It carries no gate, no block, no warning. It is the lowest-weight relationship — an annotation of meaningful proximity, nothing more.

Bloc — atomicity

A set of items that must be treated as an all-or-nothing prioritization grouping.

Enforcement: A Bloc member cannot receive a commitment-quality prioritization disposition unless all Bloc members are present in the comparison scope. Partial Bloc representation in a scope is a block — not a warning.

When a Bloc is de-selected, items outside the Bloc that have hard Dependencies on Bloc members are surfaced. De-selecting a Bloc has downstream effects that cannot be silent.

Dependency — prioritization constraint

A directed relationship indicating that the prioritization treatment of one item must account for another.

Subtype	Enforcement
`informational`	Context only — no gate
`soft`	Warning — selecting one without the other may reduce expected value
`hard`	Blocks commitment-quality disposition until the dependency condition is explicitly addressed

Critical distinction: Dependency in this system is about prioritization legitimacy, not execution order. A hard Dependency on Item B does not mean “build A before B.” It means “selecting A for commitment without explicitly addressing the dependency condition involving B is not fully legitimate.”

Hard Dependencies attached to Aggregation children surface at parent commitment time. Hard Dependencies attached to Elaboration children surface only when that specific child is selected as the approach.

Aggregation — composition

A parent item that comprises child items and acts as the roll-up object for prioritization at a higher altitude.

Enforcement: When an aggregation parent is committed, the system walks the aggregation tree and surfaces all hard dependencies on any aggregation child. Children are constituent parts of the parent — their dependencies are always relevant when the parent is committed.

An item may simultaneously be a child in an Aggregation and a parent in an Elaboration.

Elaboration — response

Child items that express alternative responses to a parent need.

Subtype	Meaning
`solution_spectrum`	Children differ mainly in ambition, altitude, or investment level
`solution_variant`	Children differ mainly in approach while addressing the same need

Enforcement: Elaboration children’s dependencies surface only when that specific child is selected as the committed approach. A hard Dependency on an Elaboration parent is not fully resolved until both the parent is prioritized and a specific child approach has been selected.

Lineage — structural transformation

Records what happened to an item over time — not an active relationship, but a provenance record.

Subtype	What happened
`split`	One item became multiple successors; original retired
`merge`	Multiple items became one successor; originals retired
`supersede`	One item replaced another; replaced item closed with a pointer
`retire`	Item ended with no successor
`fork`	One item branched into a successor; original remains active

Lineage is not an active relationship. It answers “where did this come from?” and “what happened to that?” It does not govern comparability, atomicity, or execution.

Lineage fires automatically at structural transformation time. After a supersede or fork, all relation-native records (Bloc membership, Dependencies, Aggregation structure) must be explicitly reviewed and remapped. No automatic inheritance.

Declared vs emergent

Type	Can be declared	Can be emergent
Cluster	✓	✓ (system-surfaced candidates)
Related	✓	—
Bloc	✓	✓
Dependency	✓	✓
Aggregation	✓	✓
Elaboration	✓	—
Lineage	✓	automatic on transformation

Emergent relationships begin as candidate — they carry no enforcement weight until confirmed by a human.

Developer access

# Read all relationships for an item
GET /v1/items/:id/relationships

# Response includes type, subtype, status (candidate/confirmed/dismissed), directionality, rationale

Item Relationship Graph