Hall: a typed relationship between two rooms

A hall is a typed edge between two rooms in the same wing.

export interface Hall {
  id: string; wingId: string;
  fromRoomId: string; toRoomId: string;
  relation: HallRelation;
  weight: number;
}

What the typing buys

An untyped link says two topics are related. A typed one says how, and that is the difference between a graph you can traverse deliberately and one you can only wander.

"Authentication depends on session storage" and "authentication contradicts the old token model" are both edges. Following the first to gather prerequisite context is useful. Following the second the same way imports a description of something that is no longer true.

Weight

weight makes traversal rankable. Recall is budget-bounded, so following every edge from a room is not an option — the weight is what decides which edges are worth the tokens.

Directional, and within one wing

fromRoomId and toRoomId are ordered: A depending on B is not B depending on A, and collapsing that would make the relation type meaningless.

Halls stay inside a wing. Crossing between wings requires a tunnel, which is a deliberately separate and rarer construct.

Where relations come from

The relation types are a closed set, which means whatever populates the graph has to classify each edge rather than invent a description. A closed vocabulary is harder to write against and far easier to traverse — an open one degrades into free text that no query can rely on.

The maintenance problem

Relation graphs rot in a specific way: edges are added when knowledge is created and rarely revisited when it changes. An edge asserting that one topic depends on another stays in the graph long after the dependency is removed.

Nothing in this type addresses that. There is no validity window and no supersession, so a stale hall looks exactly like a current one. Temporal validity exists elsewhere in the model, for triples, but not here — worth knowing before treating traversal results as current fact.