Units & Semantics

Reach for this when a numeric property tracks a physical measurement — a temperature, a flow rate, a power draw. Declaring the quantity with semanticType makes Sixb validate the unit on every telemetry value, so you can't silently mix Celsius readings with millibars.

Money is not a unit. Business amounts are modeled as amount (double) plus a currency stringEnum — there is no Currency quantitative type. Only the physical quantities listed below are valid semanticType values.

The canonical business domain is unitless: Project.progress and Department.headcount are plain telemetry integers with no semanticType. Units come into play only when a property tracks a physical quantity — for example a facility temperature an operations platform also records:

import { defineObjectType, prop } from "@sixb/core/ontology"

export const Facility = defineObjectType({
  id: "Facility",
  name: "Facility",
  properties: [
    prop("id", "string", { required: true, primary: true }),
    prop("name", "string", { required: true }),
    prop("temperature", "double", {
      mode: "telemetry",
      semanticType: "Temperature",
    }),
  ],
})

semanticType

semanticType is an option on prop(...) whose value is a quantitative type id ("Temperature", "Pressure", "Power", …). It only makes sense on numeric schemas — "double", "integer", or "decimal".

Declare it once on a shared value type to keep many properties consistent:

import { defineValueType } from "@sixb/core/ontology"

export const TemperatureReading = defineValueType({
  id: "temperatureReading",
  name: "Temperature Reading",
  schema: "double",
  semanticType: "Temperature",
})

Any property that references temperatureReading inherits the Temperature constraint automatically.

How units validate telemetry

When you append telemetry, pass the reading's unit. Sixb resolves the property's semantic type (from the property or its value type) and checks the unit against the quantity's catalog before writing.

await sixb
  .objects(Facility)
  .byId("facility-1")
  .telemetry(Facility.p.temperature)
  .append({ value: 21.5, unit: "degreeCelsius", at: new Date() })

The rules:

Errors are [Sixb]-prefixed. The invalid-unit message names the property path and quantity:

[Sixb] Invalid unit 'millibar' for Facility.temperature (Temperature)

The quantitative types catalog

The registry lives in @sixb/core (and is re-exported from @sixb/core/ontology), keyed by quantitative type id. Each entry names a physical quantity and lists its valid units, where every unit has a name and a display symbol. The full set of ids:

A few example unit sets:

Units API

These helpers and types are exported from @sixb/core for browsing and validating units at runtime:

Type-level helpers: QuantitativeTypeId, UnitId, and UnitsOf<Q> (the unit id union for one quantity).

import { getUnit, getUnitSymbol, isValidUnit, quantitativeTypes } from "@sixb/core"

quantitativeTypes.Temperature.units.degreeCelsius.symbol // "°C"

isValidUnit("Temperature", "degreeCelsius") // true
isValidUnit("Temperature", "millibar")      // false

getUnitSymbol("kilowattHour") // "kWh"
getUnit("degreeCelsius")
// => { name: "Degree Celsius", symbol: "°C", quantitativeTypeId: "Temperature" }

import type { UnitsOf } from "@sixb/core"

type TempUnit = UnitsOf<"Temperature">
// => "degreeCelsius" | "degreeFahrenheit" | "kelvin"

Related

• Properties — declaring semanticType on prop(...)
• Value Types — sharing a semantic type across properties
• Telemetry — appending values with a unit
• Object Types — where properties live