Skip to main content
July 3, 2026

​
New features

​
Symphony Knowledge Vector surfaces are now declared

Symphony now publishes contracts for the four surfaces that govern how canonical platform knowledge is discovered, versioned, and published:
  • SKV — the living knowledge framework of Symphony.
  • SKVI — the Symphony Knowledge Vector Index. Maps the locations, scopes, descriptors, ownership boundaries, and relationships of canonical knowledge-vector files, so agents and humans can discover the knowledge layer without having to infer its structure. SKVI is an autonomous peer surface, not something hidden inside SKV.
  • SCLV — the structured change vector. Records canonical changes, dependencies, migration events, compatibility consequences, and architectural deltas. SCLV complements Git history and PR review rather than replacing them.
  • SODV — the Symphony Official Documentation Vector. Governs how internal canonical knowledge becomes public-facing documentation.
What this means for you:
  • The platform’s truth hierarchy is now explicit: declared contract → code → derived projections → compatibility state.
  • The publication hierarchy is explicit: canonical source truth → SKVI indexing → SCLV change records → SODV publication governance → published documentation.
  • Any published docs (including this site) are a derived public projection — the canonical repository knowledge files remain the source of truth.
See Core Concepts → Architecture for how these surfaces fit into the Symphony model.

​
Symphony validator contract

Symphony has declared the boundary for its upcoming C++ validator. The validator will be deterministic, explainable, and non-agentic: it produces structured evidence for humans, CI systems, quanuxctl, and agentic tools, but does not infer intent, rewrite files, choose remedies, or make architecture decisions. Two projections are frozen up front so you can plan integrations:
  • JSON — the structured evidence projection for CI and tools.
  • Markdown — the projection for agent and human ingestion.
No validator implementation, build files, or CI wiring ships in this seed — the contract only. The validator will be written in C++ so the administrative spine does not require Python at runtime; optional isolated Python habitats remain available where a module or tool explicitly declares them.

​
Bug fixes

  • Corrected term drift in the hotpath-runtime module contract documents so wording matches Symphony’s declared doctrine. The module still owns the native hot path, is not a troll, and does not require Python for remote native hot-path execution or the administrative spine. See Core Concepts → Node Types.