Links

Relationships are facts too

A link is a typed, directed relationship between two objects. Stays in. Holds. Opens. Watches. Links carry provenance and state exactly like attributes do.

LINKS · ONE SHAPE, EVERY INDUSTRY Objects and verbs declared once. Each industry renames the labels; ids never move. placesforemitssendsgeneratesobserved atCustomerOrderAssetAccesseventMessageInvoiceIncidentTHE SAME LINK, SEVEN VOCABULARIESSLOTGENERICHOSPITALITYMANUFACTURINGHVACCLINICSINSURANCEactorCustomerGuestOperatorCustomerPatientPolicyholderorderOrderReservationProduction orderWork orderAppointmentPolicyassetAssetUnitLine / MachineEquipmentRoomInsured asseteventAccess eventAccess eventDowntime eventService visitCheck-inClaim eventThe verb "places" links slot actor to slot order in every industry. Rename the labels; the graph, the policy and the connectors do not change.

Most questions about an operation are questions about links. Who is on the north line tonight is not a lookup in one table. It is a walk. Asset, back along assigned to, to an Order, back along placed by, to a Customer. The graph answers it without a model because the path is data.

Links are typed from the same fixed vocabulary as objects, so a door can open a room but an order cannot. That constraint is what lets the system refuse nonsense instead of storing it.

Because a link is a fact, it can be proposed, conflicted or unknown. A sensor that sees a person at a door proposes a link. Whether that person holds tonight's order is a second question with its own answer.

Worked example · An access event

At 22:14 a door reports an unlock. The event becomes an object linked to the Door. The Door is linked to the Area, the Area to tonight's Order, the Order to its Customer. "Who opened the east door at ten?" is three links and no model.

a worked example in generic terms; every operation renames the labels, the shapes do not change