Skip to main content
HSV (Human State Vector) is the typed intermediate representation in the Synheart engine pipeline. It is what the Synheart Runtime emits from each inference head. Flux is the engine component that packs HSVs into HSI 1.3 payloads for the wire. This page documents the canonical Hsv struct emitted by the Synheart Runtime’s inference engine.

Pipeline placement

Hsv is what the Synheart Runtime emits per inference head. Flux consumes InferenceOutput (or &[Hsv]) and produces an HSI payload via HsiBuilder::build_from_output(...).

The seven canonical heads

HsvType enum (all caps on the wire, snake_case in JSON): The inference engine can be configured to enable a subset; default is all six core heads + MotionState.

Hsv struct

HSV invariants

Hsv::validate() enforces:
  • confidence ∈ [0, 1].
  • Every scalar value in value (whether Scalar or each entry of Multiscalar) is in [0, 1].
  • window.end_ms > window.start_ms.
Higher values mean more of the named property. Axis inversion is forbidden across versions — once a head emits focus where higher means more focus, it cannot flip semantics.

Tier-capped confidence

The inference engine caps confidence by signal fidelity tier so proxy signals never over-report certainty: The Tier-4 ONNX guard short-circuits Emotion/Focus/Capacity to rulepack inference when the window carries fewer than 5 HR samples — no probabilistic inference on single-snapshot signals. The per-modality TierBundle is the canonical 1.3 carrier; the source_tier field on Hsv mirrors its physiological entry for convenience.

64D Johnson-Lindenstrauss embedding

InferenceOutput.embedding carries a 64-dimensional, L2-normalized, deterministic, non-invertible projection of the HSVs:
Properties:
  • Always 64 dims.
  • Always L2-normalized to unit norm.
  • Deterministic — identical HSVs produce byte-identical vectors.
  • Privacy-preserving — Johnson-Lindenstrauss random projection is non-invertible: you cannot reconstruct the underlying HSVs from the embedding.
Flux consumes the embedding pre-computed via HsiBuilder::build_from_output(InferenceOutput). The fallback path HsiBuilder::build(&[Hsv]) recomputes the embedding from HSVs — same result, just an extra projection step. When the embedding reaches the HSI payload, capability level + HSI version control whether it appears in the output.

InferenceOutput

Inference engine entry points:

HSV → HSI mapping (Flux)

HsiBuilder (in the flux engine component):
  1. Takes &[Hsv] plus the embedding vector + optional integrity tag.
  2. Maps each HSV onto an HSI axis reading via flux::export::map_axes(hsvs, window_ids, default_source_ids).
  3. Writes evidence_source_ids from hsv.providers (or the builder’s defaults when providers is empty).
  4. Forwards breakdown entries as one HSI axis_reading per component.
  5. Forwards notes to axis_reading.notes.
  6. Carries the 64D embedding into embeddings[] if capability/policy permits.
  7. Stamps source_tier and tiers into the HSI envelope.
  8. Returns a validated HsiPayload.

Why HSV exists alongside HSI

Flux is the boundary that converts the in-process typed shape into the wire shape. Producers that don’t run the Synheart Runtime can still emit HSI directly; SDK consumers never see HSV — they only ever see HSI 1.3 JSON.

What the Synheart Core SDK exposes

The SDK does not expose Hsv directly to host code (Dart/Kotlin/Swift). It exposes:
  • The HSI JSON via Synheart.onHSIUpdate — what flux emitted.
  • Typed HSIState (axes, modalities, tiers) via Synheart.onStateUpdate — parsed from the HSI JSON; see HSI in Synheart Core.
Apps that need direct Hsv access integrate at the runtime / engine level — typically only research-tier integrations.