Skip to content
sigMAX logo sigMAX documentation v0.30 Secure Integrated Generator of Modular Architecture
AdminRepository
About Documentation FrontMark Contact
AdminRepository

ObjectIR and DocIR

ObjectIR and DocIR

Section titled “ObjectIR and DocIR”

sigMAX can separate business data from document rendering.

sigMAX distinguishes two intermediate representations.

ObjectIR → business data

Structured, typed objects produced by runtime logic.

API responses · validation payloads · event data

DocIR → documents

Document-oriented representation for Markdown, HTML, PDF or other rendered formats.

Documentation · reports · generated pages

Both representations can be validated, transformed and rendered by the runtime. Their separation keeps documents traceable and presentation distinct from business state.

Structured output and host renderingA WASM handler produces ObjectIR or DocIR according to the route. The host checks the output and renders ObjectIR as JSON or DocIR as a supported document format. These are alternative representations, not consecutive conversions.WASM handlerObjectIRor DocIROutputvalidationRouterendererJSON ordocument

These are alternative output paths: ObjectIR becomes JSON; DocIR becomes HTML, Markdown or bounded PDF where supported by the route and executor. The diagram does not imply an automatic ObjectIR-to-DocIR conversion. The separate c_repr memory layout is described below.

Purple identifies execution, blue identifies the chosen representation, amber marks output checks, and the rounded processing step renders the response. In the Rust runtime, the route’s response source and format select the renderer; unsupported combinations fail explicitly.

Execution and Representation

Section titled “Execution and Representation”

ObjectIR and DocIR describe data, not deployment isolation. Core executes WASM in a container on the same host as Host and Config, without a dedicated execution boundary. Pro uses the COS2000 executor in a KubeVirt VM under Kubernetes. The executor interface must preserve the supported data representation and ABI; a matching format name alone does not establish compatibility.

ObjectIR and Binary Layout

Section titled “ObjectIR and Binary Layout”

ObjectIR is the structured value model used by the runtime.

When a route expects or returns a typed binary object, the runtime can translate between JSON-like ObjectIR data and a compact c_repr buffer. This buffer is suitable for WASM modules compiled from a deterministic C subset because both sides can agree on field offsets, primitive numeric types, booleans and fixed-size character arrays.

For the Rust container runtime, the separation is:

Layer Responsibility
Rust runtime Implements host primitives, validates inputs, encodes and decodes typed values, and controls access to runtime capabilities.
c_repr layout Defines the binary memory representation exchanged with WASM for selected typed values.
WASM module Executes logic and exchanges values through explicit primitive imports in the edition’s execution environment.
ObjectIR Keeps business values structured and typed before or after binary encoding.
DocIR Keeps rendered document state separate from business objects.

Primitives describe runtime capabilities. Their implementation belongs to the selected executor: the Rust host in the container runtime, or the native provider in COS2000. The C-compatible part of c_repr is the ABI layout used for WASM exchanges, not a requirement to implement every primitive in one language.

ObjectIR · structured values

Typed business data, stable API structures and validation-friendly payloads for events, object responses and runtime state.

DocIR · structured documents

Renderer-independent content for Markdown, HTML, PDF and reports, with presentation traceable to generated state.

Back to top