Relations

Atoms are nodes. Edges are typed and named. AtomPRD ships 20 relation types grouped into nine families:

Family	Relations
Hierarchy	parent_of
Data semantics	uses_entity, uses_rule, rendered_by, renders_feature
API	exposes_endpoint, returns_entity
RBAC	requires_permission, granted_to_role, scoped_to_resource
UI flow	navigates_to
State machine	transitions_to, owned_by
C4 architecture	contains, uses_container, uses_tech
Cross-cutting	depends_on, blocks, verifies
Attribution	mined_from

Why typed?

A typed edge:

• Validates against the kind pair. verifies is criterion → feature, never entity → criterion. The validator catches the wrong shape.
• Drives Pattern C inference. The cloud’s behaviors.service.ts walks specific relation types per atom kind to deterministically synthesise Layer 2.
• Powers MCP query_relations. An agent can ask for verifies edges only, getting back the criterion ↔ feature graph without scanning every atom.

See RFC-001 — Relation kind enforcement for the full type-pair matrix.

Key relations to know

The handful you’ll see most often in practice:

Relation	From → To	Purpose
parent_of	module → feature, feature → block	Hierarchy. The block tree is built from these edges, not nested fields.
verifies	criterion → feature	A criterion verifies that a feature works. Drives Pattern C criterion ↔ feature inference.
rendered_by	entity → ui_view	This entity is shown in this view. Drives Pattern C ui_view template selection.
uses_entity	feature → entity	This feature reads / writes this entity.
uses_rule	feature → rule	This feature applies this rule. Drives Pattern C rule.enforced_at.
depends_on	feature → feature / integration	Cross-cutting dependency.
blocks	task → task	Sequencing in a sprint.
mined_from	any → any	This atom was extracted from that other atom (e.g. a criterion mined from a feature description).

Pattern C inference table

The deterministic inference logic per atom kind (cloud-side, but the rules are spec-fixed):

Kind	Walks edges	Pulls into
feature	verifies reverse → criteria	before_after.api_calls → call steps. state_diff → setState steps.
ui_view	rendered_by → entity	Apply viewType template (list → 3-screen, form → 1-screen, detail → 1-screen, custom → stub) over the entity’s fields.
rule	uses_rule reverse → features	Emit pre_call enforced_at entries.
criterion	verifies → feature	Pull feature’s behavior.steps (call, setState) into before_after.api_calls + state_diff.
fixture	metadata.linked_criteria	Pull each criterion’s before_after into before/after/api_calls.

Without these edges Pattern C cannot run — it falls back to Pattern D (LLM) or Pattern B (convention default). If your inferred Layer 2 looks empty, check the relation graph first.

See also

• Atom model — atoms as nodes, edges as relations.
• Spec → Relations — exact from/to kind pair matrix.
• RFC-001 — enforcement rationale.