Skip to main content
Use this guide to orient yourself before operating Symphony. The documentation separates platform doctrine, user-selected infrastructure, vector-owned semantics, and administrative commands. Exact installation and execution steps belong to the relevant component’s current contract.

​
1. Read the operating boundaries

Start with the platform doctrine. It establishes user ownership of strategy and infrastructure, caller-class neutrality, evidence-based compatibility, and protection of the hot path.

​
2. Learn the physical model

Read Node, Habitat, and Nest:
  • Node: the identified physical computer resource.
  • Habitat: the exact operating system and package conditioning delivered to a Node.
  • Nest: the user-purpose workload placed into a suitable Habitat.
A cluster’s buses and adapters are explicit architectural choices. Symphony does not prescribe a universal provider or strategy.

​
3. Trace ownership of meaning

The architecture overview shows the relationship between vector contracts, engines, qxctl, and governed evidence. Vectors and phases explains why a vector remains the semantic owner even as delivery work moves through phases. The Symphony Knowledge Vector describes the Contract Quad and its companion surfaces.

​
4. Find the administrative surface

The qxctl overview introduces the Go administrative and query CLI. Use the qxctl pages for a specific command family, such as knowledge, lifecycle, engines, or validation. qxctl provides command grammar and presentation; vector contracts own the operations and their meaning.

​
5. Check the relevant contract and evidence

Before acting on a Node or invoking a vector engine, check the current owner contract, target state, authorization, and available receipt or validation evidence. Caller authority and hot-path isolation explain those boundaries. An emerging surface is not an implicit operational guarantee.
Last modified on September 24, 2026