Skip to main content
The Symphony Node Vector (SNV) records and relates the identities, resources, cluster memberships, and names of the physical Nodes you use with Symphony. It is composed of four subvectors that each own a distinct semantic boundary. SNV does not choose, issue, dictate, or automatically rename anything on your behalf.

​
Subvector composition

SNV is built from four enduring semantic domains:

SNIV

Node Identity: physical Node identity and its exact provider-resource, selected-offering, and infrastructure-domain associations.

SNRV

Node Resources: local and explicitly qualified remote resource truth for a Node.

SCIV

Cluster Identity: cluster identity, bus connectivity, and Node-in-cluster relationships.

SCNV

Consolidated Naming: SNV-bounded resolution of names already assigned by you or your providers.

​
Recording boundary

SNV records facts and their lineage. It does not reserve names, allocate resources, or create clusters for you. Names are user-assigned; Symphony records them. Provider resources are user-selected; Symphony relates them. Cluster topology is user-designed; Symphony documents it.

​
How SNV relates to other vectors

SCV

Supplies provider and offsite resource knowledge that informs what Nodes can exist.

SOV

Establishes and changes infrastructure through qxctl, producing the Nodes SNV records.

SHV

May supply detailed hardware capability evidence for the physical components inside a Node.

​
Current status

SNV is an emerging canonical architecture contract. No SNV engine, graph, registry schema, identity encoder, discovery service, naming service, or qxctl command is currently implemented. Record schemas and engines remain deferred.

​
Future installability

Any future SNV engine must be independently installable and capable of rebuilding its projections from exact owner evidence. No engine becomes an identity or naming authority merely by storing or resolving records.
Last modified on September 24, 2026