RFC-001 — Relation kind enforcement

Status: ratified. Source: atomprd/specs/rfcs/RFC-001-relation-kind-enforcement.md.

Summary

Every relation type in AtomPRD is constrained to specific (from kind, to kind) pairs. The validator rejects edges with disallowed pairs.

Most-used pairs:

Relation	From	To
parent_of	module / feature	feature / block kinds
verifies	criterion	feature
rendered_by	entity	ui_view
uses_entity	feature / ui_view	entity
uses_rule	feature	rule
transitions_to	ui_view	ui_view
requires_permission	feature / ui_view	(free-text role on metadata)

depends_on, blocks, and mined_from accept any kind pair — they’re cross-cutting and intentionally unconstrained.

Why enforce

• Pattern C inference relies on kind-typed walks. “Walk verifies reverse from this feature to find criteria” only works if verifies is guaranteed criterion → feature.
• Validator catches the wrong shape early. A user trying to wire verifies: feature → criterion (reversed) gets a clear error.
• Codegen lowering is type-safe. lowerCriterion(c) can rely on c.kind === "criterion" for every node walked via a verifies edge.

Trade-offs

The cost is some judgment calls have no clean answer:

• “A risk that depends on a vendor” — depends_on is unconstrained, so this works, but it doesn’t carry kind-specific semantics.
• Adding a new relation type requires a new RFC + a kind-pair table update.

The benefit is the validator catches broken graphs at authoring time, not at codegen time.

See also

• Concepts → Relations.
• Spec → Relations — the kind-pair matrix.
• Full text: RFC-001 source.