Skip to main content
This page describes how Synheart Core implements HSI (the Human State Interface contract) inside the Synheart Core SDK.
Synheart Core’s internal state model is HSV (Human State Vector). If you’re looking for the internal axes/indices/embeddings model, see:
If you’re looking for the general, SDK-agnostic HSI contract, start here:

​
What Synheart Core does with HSI

Synheart Core is an implementation that can:
  • Produce HSI-compliant payloads from on-device signals and inference.
  • Consume HSI payloads as an interoperability boundary between producers and downstream consumers.
This page intentionally does not redefine the contract fields; it focuses on implementation guidance and how to think about HSI when integrating Synheart Core.

​
Mapping: Synheart Core runtime → HSI payload

At a high level, Synheart Core maintains an internal “runtime state” and emits it as an HSI payload by:
  • Defining windows: choose one or more window definitions and reference them by id.
  • Emitting readings: place normalized scores under axes.*.readings[] and scope each reading to a window_id.
  • Declaring sources (optional): when source quality/degradation matters, include sources + source_ids and link them via evidence_source_ids.
  • Emitting embeddings (optional): include embeddings[] only when privacy policy allows and you can support the contract requirements.

​
Validation expectations

Synheart Core aims to produce payloads that meet:
  • HSI-VALIDATE-BASIC: structural + range validation against the JSON Schema for the claimed major version.
  • HSI-VALIDATE-STRICT: cross-field integrity checks (references, time ordering, and dimension checks).
When you consume HSI payloads, you should validate at least BASIC, and ideally STRICT, before using readings. HSI requires privacy.contains_pii=false. Synheart Core’s privacy posture is documented here:
Implements: HSI 1.0
Last Updated: 2025-12-28