Relations

Relations are typed edges between atoms. The 20 types are grouped into nine families:

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

Edge shape

{
  "type":     "verifies",
  "from":     "cri_initial_load_h31a",
  "to":       "feat_load_habits_a7b3",
  "metadata": { /* optional, kind-specific */ }
}

Each edge is a row. The pair (from, to, type) is unique within a project.

Block hierarchy

Project → Module → Feature → Block is expressed via parent_of edges, not nested fields. Each block atom is its own row in storage. This means:

Independent diffs.
Independent versioning.
Independent context windows.

See Atom model for the rationale.

Kind-pair enforcement

Relations are constrained to specific from / to kind pairs. The validator rejects edges with the wrong shape. The full pair matrix lives in RFC-001; the most-used pairs:

Relation	From kind	To kind
`parent_of`	`module` / `feature`	`feature` / block (`description`, `criterion`, `task`, etc.)
`verifies`	`criterion`	`feature`
`rendered_by`	`entity`	`ui_view`
`renders_feature`	`ui_view`	`feature`
`uses_entity`	`feature` / `ui_view`	`entity`
`uses_rule`	`feature`	`rule`
`exposes_endpoint`	`service`	`feature`
`returns_entity`	`feature`	`entity`
`requires_permission`	`feature` / `ui_view`	(free-text role on metadata)
`navigates_to`	`ui_view`	`ui_view`
`transitions_to`	`ui_view` (state)	`ui_view` (state)
`contains`	`service`	`service`
`uses_container`	`feature`	`service`
`uses_tech`	`service`	`vendor`
`depends_on`	any	any
`blocks`	`task`	`task`
`mined_from`	any	any

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

Pattern C inference uses these edges

When the cloud authoring service computes a Pattern C suggestion for an atom’s Layer 2, it walks specific relation types:

Atom kind	Walks
`feature`	`verifies` reverse → criteria with Layer 2 filled
`ui_view`	`rendered_by` → entity + its `field` children
`rule`	`uses_rule` reverse → features
`criterion`	`verifies` → feature
`fixture`	`metadata.linked_criteria` → criteria

Without these edges, Pattern C cannot synthesise — it falls back to D (LLM) or B (codegen-time defaults). See Concepts → Relations for the full inference table.

Relations

Edge shape

Block hierarchy

Kind-pair enforcement

Pattern C inference uses these edges

See also