How entities connect

A connection is a way one entity can be linked to another. Your world arrives with a few dozen of them already defined, which covers most of what people need. This page is about what a connection is made of, so that you can adjust one or add your own.

Open World Settings → Building Blocks → How entities connect to see the list.

Two sides of the same fact

Suppose you record that Ann is the parent of Ben. You record it once, but it can be read from either end. On Ann’s page it reads as Parent Of and points at Ben. On Ben’s page the very same fact reads as Child Of and points back at Ann.

That second reading is what the editor calls the name from the other side. A connection needs one because its two ends are not interchangeable. Being someone’s parent is not the same as being their child, so the link needs a name in each direction.

Now suppose you record that Ann and Ben are siblings. Read from either end, that fact says the same thing. There is no second name to supply, because Sibling Of is already how it reads from both sides. For a connection like this you tick works both ways and give a single name.

As you type, the editor shows you how the connection reads in each direction. It is worth a glance, because a reverse name that sounded right on its own often reads badly once it is in place.

One thing to expect when you open a connection that already exists: the box holds the underlying key rather than the tidy version, so Works At shows WORKPLACE_OF where the list and the preview both read Workplace Of.

Which kinds can be connected

Two columns, starts from and goes to, control which kinds the connection is allowed to join. Parent Of starts from a Person and goes to a Person. Lives At starts from a Person and goes to a Place.

There is a trap here worth understanding. Everything ticked on the left may connect to everything ticked on the right, in every combination. If you tick Person and Group on the left, then Item and Project on the right, you have not created two tidy pairings. You have also allowed a Group to connect to a Project. When different pairs genuinely need different rules, make a second connection rather than widening the first one until it covers everything.

Either column can be set to any kind, which is how the broadest connections work. References runs from any kind to a Reference, so anything at all can cite a source. Applies To runs from a Rule to any kind, so a rule can govern anything in the world.

What a connection records

A link can carry details of its own, kept separate from the entities at either end. You will find this in the editor under What this connection records, and it uses the same details that a kind does.

The purpose is to hold facts belonging to the relationship rather than to either party. A Works At connection might record a job title and a start date. That job title belongs to the pairing of one particular person and one particular employer. It is not a fact about the person alone, and it is not a fact about the company alone.

This section appears only once a connection exists. When you are creating a new one, save it first, then reopen it to add what it records.

Keeping the list tidy

A connection can be given an optional group, which keeps similar connections next to each other in the list rather than heading them separately. The values read like person_to_place, and the list itself shows no group titles, so the effect is simply that related connections sit together. With a few dozen connections in a world, that ordering is what makes the list scannable.

Names and removal

A connection has a display name that people see and a fixed key that your AI writes, such as PARENT_OF. This works just as it does for kinds. Renaming changes the label, and the key stays as it is.

Deleting a connection is permanent, and the change log does not reverse it.