Typed Payload and Codec Guide
This page explains how typed payloads are encoded and decoded across SDK languages.
It is not the subsystem method catalog. For lifecycle, Event, Control, Procedure, and Operation methods, use Subsystem SDK API. For message/API contract/component definitions, use Spec. For the detailed binary encoding reference, use Data Types And Binary Encoding.
Librux uses one canonical message codec across language SDKs. Language SDKs use the installed runtime library instead of defining incompatible transport encodings.
Encoding Model
The binary encoding baseline is this.
- primitives are little-endian
- dynamic vectors use a
uint32element count followed by packed element bytes - fixed arrays use packed element bytes without an inner count
- compound messages encode fields in schema order
- nested composites are allowed through local or canonical message refs
Typed Transport Path
Typed Control, Procedure, and Operation calls use message refs such as the following.
msg.core.common.primitive.v1/Int32Value
msg.core.common.primitive.v1/IndexedBoolValue
The wrapper encodes JSON-like language values into canonical bytes before transport, and decodes response bytes back into language values after transport.
Timing Envelope
Timed Exchange currently uses a compact binary envelope around a typed payload.
The endpoint declares the domain payload type separately.
request_type: msg.core.common.primitive.v1/Int32Value
response_type: msg.core.common.primitive.v1/Int32Value
timing_support: required
This prevents timing metadata from becoming part of every domain message.
Endpoint timing policy (none, optional, required) belongs to endpoint
registration and is documented in Subsystem SDK API.
Performance Rule
High-frequency array payloads should use packed primitive arrays or schema messages containing packed vectors.
Avoid element-by-element JSON or nested per-element encoding in hot paths.