frontend-patterns/canon/Relations.md

# Pattern Relations

The language is primarily a graph.

## Core relations

### requires

Pattern A needs Pattern B. Cite its stable pattern ID and explain why. Conditions
that do not require a particular pattern belong in `prerequisites`, not graph edges.

### enables

Applying A makes B possible or substantially easier.

### creates-context-for

A changes the system such that B becomes a relevant subsequent decision.

This is especially important for generative sequences.

### refines

A is a more specific realization of B.

### generalizes

A captures the common structure of several more specific patterns.

### complements

A and B solve different parts of a larger problem and commonly reinforce each other.

### alternative-to

A and B address substantially the same problem using different trade-offs.

### conflicts-with

The assumptions or consequences of A and B are structurally incompatible or create severe tension.

### commonly-combined-with

Empirical relation based on frequent co-occurrence.

### implemented-by

Links a pattern to technologies or concrete mechanisms.

### observed-in

Links a pattern to known systems or architectures.

## Relation semantics

Relations should be directional where possible.

For example:

```text
Server Authority
    creates-context-for → Server Projection
```

is more informative than:

```text
Server Authority
    related-to ↔ Server Projection
```

Avoid a generic `related-to` relation unless no stronger relation can be justified.


## Serialization contract

Use the typed relation records in [PatternSchema](PatternSchema.md) and the
kebab-case keys in [vocabulary.yaml](vocabulary.yaml). Pattern endpoints resolve by
stable FEP ID; technology, system and architecture endpoints resolve to existing
repository paths. Human-readable names in diagrams are explanatory labels only.