Schemas / Node graph
rig.node.bus
v1.0.0 · stable maturity: draft 3 fields 3 required
Fields
| Field | Type | Meaning | |
|---|---|---|---|
id |
uint | required | Stable id within the graph |
name |
string | required | Rail label (ground, clock) |
type |
propertyType | required | Property datatype id - see properties, same table as pin type |
Named rail inside a rig.node.graph - a signal every node in the graph can tap without a drawn link (ground, master clock). Nested POD like pin and link, not a separate ECS entity.
Rules
- A pin taps a bus through its own
busfield - do not store a member list here (same member-points-at-rail shape asrig.circuit.net). - At most one
outpin drives a bus. Any number ofinpins read it. - An undriven bus reads as its
typedefault (zeros / empty). - An
inpin that taps a bus is not also a link target - one source per input. - A bus is scoped to its graph. A
nestedgroup has its ownbuses; the group interface stays outer pins +publish. - Pin
typematches bustype; hosts may allow the same documented coercions as pin linking.
How a host draws the tap (a small tag at the pin, a ground-style symbol) is editor chrome; only the fields above travel.
Not rig.circuit.net - that is electrical potential on circuit entities. Different graph; do not merge.
JSON Schema
Resolves at https://rig.works/schemas/rig.node.bus.schema.json —
raw file.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://rig.works/schemas/rig.node.bus.schema.json",
"title": "rig.node.bus",
"type": "object",
"additionalProperties": false,
"properties": {
"id": {
"$ref": "./_defs.schema.json#/$defs/uint"
},
"name": {
"$ref": "./_defs.schema.json#/$defs/string"
},
"type": {
"$ref": "./_defs.schema.json#/$defs/propertyType"
}
},
"required": [
"id",
"name",
"type"
],
"x-rig-maturity": "draft"
}