Reference
Edge Types
Edge kinds express how members relate inside a rig topology. The important distinction is that only two kinds currently affect runtime behavior: `delegates_to` and `spawned_by`.
For raw YAML placement rules, see RigSpec.
Accepted edge kinds
delegates_to
Accepted and runtime-significant
Source delegates work to target. Constrains launch order.
spawned_by
Accepted and runtime-significant
Target was spawned by source. Constrains launch order.
can_observe
Accepted, informational
Source can observe target output. No launch-order effect.
collaborates_with
Accepted, informational
Peer collaboration relationship. No launch-order effect.
escalates_to
Accepted, informational
Source escalates to target for decisions. No launch-order effect.
What edges actually do today
`delegates_to` and `spawned_by` affect launch ordering during initial boot and restore.
All accepted edges render in the topology graph.
All accepted edges appear in `rig whoami --json` under incoming/outgoing relationships.
The post-command attach hint prefers nodes with outgoing `delegates_to` edges.
What edges do not do yet
They do not route messages or constrain who `rig send` can target.
They do not enforce permissions or access control.
They do not change how `rig capture`, `rig broadcast`, or chatroom transport works.
Authoring examples
# Orchestrator -> worker
edges:
- kind: delegates_to
from: orch.lead
to: dev.impl# Reviewer -> implementer
edges:
- kind: can_observe
from: rev.r1
to: dev.implWhen you are not sure
If one agent gives work to another, use `delegates_to`.
If one agent mainly watches another's output, use `can_observe`.
If they are peers, use `collaborates_with`.
If one reports decisions up the chain, use `escalates_to`.
If one created the other, use `spawned_by`.