Skip to content
sigMAX logo SIGMAX Development Documentation v0.72 Secure Integrated Generator of Modular Architecture with execution Runtime
AdminRepository
About Documentation Contact
AdminRepository

Binary Model

Binary Model

Section titled “Binary Model”

The binary layer describes and validates executable WASM artifacts.

In sigMAX, a binary is not trusted only because it was generated. It must remain tied to a Binary Contract, compiled through deterministic tooling, loaded by the runtime, and recorded in a Binary Agreement.

Model Flow

Section titled “Model Flow”

The LLM may help produce controlled pseudo-code, but the final executable is produced and checked by deterministic tooling.

guides

translates

compiles

ABI

checks

accepted

drift

records

Binary

Pseudo-code

C subset build

WASM artifact

Validate

Rust Runtime

Agreement

Reject

Binary Contract

Section titled “Binary Contract”

The Binary Contract describes what the executable is allowed and expected to be.

It can define:

  • exported functions;
  • imported host primitives;
  • input and output layout;
  • memory expectations;
  • allowed runtime capabilities;
  • execution limits;
  • expected ABI shape;
  • validation rules applied before runtime acceptance.

The contract should not contain every implementation detail. It should describe the executable boundary precisely enough to validate the compiled artifact.

Controlled Pseudo-code And C Subset

Section titled “Controlled Pseudo-code And C Subset”

sigMAX separates generative assistance from executable production.

The LLM can produce controlled pseudo-code or structured intent for a binary, but the path to WASM should remain deterministic. A restricted C subset can be used as an intermediate form when it helps keep compilation predictable and auditable.

This keeps the generated code path inspectable:

  1. the Binary Contract defines the boundary;
  2. controlled pseudo-code describes the logic inside that boundary;
  3. deterministic tooling translates and compiles the executable;
  4. the WASM artifact is validated before it is accepted.

WASM Artifact

Section titled “WASM Artifact”

The compiled WASM artifact is the executable result.

It should be checked before execution for:

  • expected exports;
  • unauthorized imports;
  • ABI compatibility;
  • memory assumptions;
  • primitive usage;
  • binary hash;
  • reproducible build metadata where available.

Binary Agreement

Section titled “Binary Agreement”

The Binary Agreement records the effective binary state.

It can include:

  • the binary hash;
  • imports and exports found in the artifact;
  • ABI validation result;
  • referenced Binary Contract version;
  • compiler or generator metadata;
  • accepted or rejected validation status;
  • drift details when the artifact does not match the contract.

Runtime Acceptance

Section titled “Runtime Acceptance”

The Rust runtime should only load a binary after the validation step has accepted the artifact.

The runtime is not the place where uncontrolled host access is granted. It is the execution boundary that exposes the allowed primitives and keeps the binary inside the contract-defined capability model.

Drift Examples

Section titled “Drift Examples”

Binary drift can appear when:

  • a WASM module imports a primitive that was not allowed;
  • an expected export is missing;
  • the ABI layout no longer matches the contract;
  • memory assumptions changed;
  • a hash differs from the recorded agreement;
  • a binary was regenerated from a different contract version.

Design Rules

Section titled “Design Rules”

A good binary model should be:

  • deterministic after the controlled generation step;
  • strict about imports and exports;
  • explicit about ABI expectations;
  • small enough to inspect;
  • tied to a Binary Contract and Binary Agreement;
  • rejected when drift affects runtime safety or behavior.