Relationship Types
A relationship type is the template every relationship is built from. When two characters have a parent-child relationship, that’s an instance of the Parent of relationship type. When a character owns a sword, that’s an instance of Owns.
Just like with entity types, you’ll work with two kinds:
- System types — the standard set ships with MythTapestry: Parent of, Member of, Allied with, Owns, Located in, and many more.
- World types — custom types you create when nothing built-in fits.
Most worlds work fine on the system relationships alone. Reach for custom types when you have a connection that’s specific to your setting and used a lot.
When to make a custom relationship type
Section titled “When to make a custom relationship type”Make a custom type when you find yourself wanting to express a specific kind of connection that doesn’t fit any built-in. A few examples that warrant custom types:
- Bound to — a magical pact between a mage and a familiar.
- Sworn to — a bond of loyalty between vassal and liege.
- Cursed by — a magical affliction.
- Trades with — a trading relationship with metadata about goods.
Don’t make custom types for one-off relationships. If you only need it once, write it as a description and move on.
Anatomy of a relationship type
Section titled “Anatomy of a relationship type”Every relationship type has a few parts. The most important ones are the four label fields.
Forward and reverse labels
Section titled “Forward and reverse labels”Every relationship has direction. Source → Target. The “forward” labels describe the relationship from the source’s perspective; the “reverse” labels describe it from the target’s perspective.
Take “Parent of”:
| Field | Value | Reads as |
|---|---|---|
| Forward name | PARENT_OF | Internal identifier |
| Forward label | ”Parent of" | "Eddard is the parent of Robb” |
| Reverse name | CHILD_OF | Internal identifier |
| Reverse label | ”Is child of" | "Robb is the child of Eddard” |
Good labels read naturally as sentences. Test them out loud before saving:
- “Eddard mentors Jon” ✓
- “Jon is mentored by Eddard” ✓
If either reading sounds awkward, rephrase.
Symmetric vs directional
Section titled “Symmetric vs directional”Some relationships are symmetric — the same in both directions. “Allied with”, “Spouse of”, “Hostile to” are all symmetric: if A is allied with B, then B is allied with A in exactly the same sense.
Other relationships are directional — the source and target play different roles. “Parent of / Child of”, “Controls / Controlled by”, “Owns / Owned by” all have a clear up-and-down.
When you create the type, mark whether it’s symmetric. The system uses this for graph display and aggregations. (Symmetric relationships only need one label pair instead of two.)
Which entity types can use this relationship?
Section titled “Which entity types can use this relationship?”You can restrict which entity types can be the source and which can be the target.
| Setting | Effect |
|---|---|
| Allowed source types | Only these entity types can be the source. Empty = any. |
| Allowed target types | Only these entity types can be the target. Empty = any. |
For “Parent of” between Characters, source = Character, target = Character. For “Located in”, source could be many things (Character, Item, Building) and target should be Location.
Restricting types prevents nonsense relationships (“a Spell is the parent of a Number”) and makes the relationship picker shorter and more relevant.
How many at once?
Section titled “How many at once?”The maximum concurrent setting limits how many active relationships of this type one entity can have:
- 1 — exclusive. “Currently lives in” should be 1; a character lives in one place at a time.
- Unlimited — the default. “Owns”, “Knows”, “Allied with” can have as many as you like.
- Other numbers — rare. Could be useful for “Apprenticed to” (typically one master at a time).
Setting this on a directional relationship limits each source entity. A character might report to many people across their career, but at any given time they should be the source of only one active Reports to relationship.
Adding context to a relationship
Section titled “Adding context to a relationship”Plain relationships are just A → B. You can add two kinds of context:
Time (temporal context)
Section titled “Time (temporal context)”Turn on temporal context to give relationships a time dimension. Each relationship gets:
- A start date — when it became active.
- An end date — when it ended (optional; empty means still active).
This is essential for relationships that change over time — alliances form and dissolve, characters change employers, treaties begin and end. The graph view’s time slider uses these dates to show what was true at any past moment.
Use temporal context for: alliances, marriages, employments, residences, conflicts, treaties, anything historical.
Skip it for: family lineage (parent-of, child-of), genre-fixed facts (species, racial heritage).
Place (spatial context)
Section titled “Place (spatial context)”Turn on spatial context to associate relationships with places:
- A primary location reference.
- An optional marker override for map display.
Use this for relationships that happened somewhere. “Battle between” might point to the battlefield; “First met at” might point to a tavern.
Most relationships don’t need this — only turn it on when the location is genuinely part of the relationship’s identity.
Subtypes
Section titled “Subtypes”Relationship types can have subtypes the same way entity types do. The classic example is “Parent of”:
| Subtype | Meaning |
|---|---|
| Biological | Standard biological parenthood |
| Adoptive | Adopted parent |
| Step | Stepparent through marriage |
| Foster | Foster parent |
| Guardian | Legal guardian, not strictly parent |
| Divine birth | Mythical / divine parentage |
Each subtype shows up in the picker when someone creates a parent-of relationship. The label can incorporate the subtype: a “biological” subtype on Parent of can read as “is the biological parent of”.
Add subtypes when one relationship has meaningful sub-categories that you want to filter or display differently. Skip them when the relationship is uniform.
Extra fields on a relationship
Section titled “Extra fields on a relationship”Just like entity types, relationship types can have custom fields. A “Trades with” relationship might capture trade goods, volume, and route. A “Married to” relationship might capture wedding date and witness.
These fields appear in the relationship’s edit form and show up in the relationship’s detail panel.
Use extra fields when the relationship has its own metadata — facts about the connection, not about the entities at either end.
Categories
Section titled “Categories”Relationship types are grouped into categories for organisation in the picker:
- Kinship — family and lineage.
- Social — membership, friendship, allegiance.
- Political — control, alliance, hostility.
- Spatial — location, containment.
- Ownership — possession, stewardship.
- Religious — worship, devotion.
- Origin — creation, founding.
- Event — participation, witnessing.
Pick the closest category when you create a custom type. If none fit perfectly, use the broadest match.
Creating a relationship type
Section titled “Creating a relationship type”- Go to Management → Relationship Types in your world’s sidebar.
- Click Create Relationship Type.
- Fill in the four labels — forward name, forward label, reverse name, reverse label. Read them out as sentences to check they sound right.
- Choose the category that fits best.
- (Optional) set source/target type restrictions, max-concurrent, temporal context, spatial context, subtypes, extra fields.
- Save.
You can edit the type later. Existing relationships of this type pick up the new labels and rules immediately.
Where you’ll see relationship types in use
Section titled “Where you’ll see relationship types in use”| Place | What you’ll see |
|---|---|
| Entity detail page | A “Relationships” panel listing every connection grouped by type. |
| Graph view | Each type has its own colour and edge style. Filters in the toolbar let you show/hide by type. |
| Aggregations | ”Count of children” walks PARENT_OF. “Total wealth” walks OWNS. |
| Lookups | ”Show parent’s homeland” walks PARENT_OF. |
| Chatbot | ”Who lives in Winterfell?” finds answers via the LIVES_IN relationship. |
If you find yourself wanting to filter by a connection type and there isn’t one, that’s usually a sign you should add a relationship type.