Relationships reference
Relationship type
Relationship types. Cardinality and the symmetric and acyclic flags are set here.
| Setting | Purpose |
|---|---|
| Source and target entity types | What it links |
| Cardinality | How many links per endpoint |
| Display name | How it reads forward |
| Inverse display name | How it reads backward |
| Symmetric | Whether direction is meaningful |
| Acyclic | Whether cycles are rejected |
Inverse display names matter for readability: one stored link should read "employs" from one end and "employed by" from the other, rather than forcing the reader to work out the direction.
Acyclic matters for hierarchies. Without it an ownership chain can close into a loop that no rollup can resolve.
Assertion states
| State | Meaning |
|---|---|
| Pending | Target not yet found; retried as data arrives |
| Resolved | A canonical edge exists |
| Ambiguous | The key matched several candidates |
| Conflicted | The target resolved, but the edge could not be created — a cardinality rule blocked it, or the rule or relationship type no longer exists |
| Rejected | A steward rejected the assertion |
| Expired | The source stopped asserting the fact; the evidence was retracted from the source record. If the evidence returns, the assertion reopens as pending. |
It is where an assertion lands when the target was found but the edge could not be materialized. A steward triaging one should look at what blocked the edge — most often a cardinality rule — rather than hunting for a competing source record.
Do not confuse expired with an edge whose effective period has ended. Those are different objects: expired is an assertion state driven by the source, while a closed period is a property of the edge. See Effectivity below.
Effectivity
Every relationship carries an effective period. A link that ends is closed, not deleted.
| Query | Returns |
|---|---|
| Default | Currently effective links |
| As-at a date | Links effective on that date |
| Filtered by state | Active, expired, or future links |
Cardinality is evaluated within the effective window, so a one-per-endpoint relationship can legitimately have several historical occupants.
Merge behaviour
| Event | Effect |
|---|---|
| Merge | Links re-point to the survivor; duplicates collapse |
| Merge with a shared counterpart | The survivor's existing link wins; the other is superseded |
| Unmerge | Superseded links are restored, then re-points reversed |
Restoring superseded links before reversing re-points is what makes the undo byte-identical rather than approximately right.
A relationship endpoint that has been merged cannot be written; the platform resolves to the survivor first, so a link cannot be stranded on an absorbed record.
Modelling rule
| The related thing is | Model as |
|---|---|
| Mastered | A relationship |
| Not mastered | An attribute |
Never both. Two copies of one fact diverge.
Next
Last verified against commit 74cecd91 (2026-08-03)