Binary Model
Binary Model
Section titled “Binary Model”The binary layer describes and validates executable WASM artifacts.
In sigMAX, a binary remains tied to a Binary Contract, the toolchain that produced it and the evidence recorded in a Binary Agreement. Validation checks that evidence before deployment; the runtime applies its own loading and execution checks.
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.
This diagram follows the Studio compilation path. COS2000 also provides the Radjae direct-to-WASM path. Both paths require validation against the selected executor; a rejected artifact must not proceed to execution.
Blue shapes identify compilation inputs and artifacts, the cylinder holds the agreement, and the amber control validates the recorded evidence. Studio creates the agreement before its separate validation report; these are distinct outputs.
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 Source Generation
Section titled “Controlled Pseudo-code And Source Generation”sigMAX separates generative assistance from executable production.
The LLM can propose controlled pseudo-code for a binary. Studio validates it with the Rust parser and produces a canonical AST. Deterministic source generation then selects C or MoonBit, and the matching compiler produces WASM. Reproducibility applies to fixed validated inputs and toolchain versions; the LLM proposal itself can vary.
This keeps the generated code path inspectable:
- Contract defines the boundary.
- Pseudo-code describes logic inside it.
- Toolchain translates and compiles.
- Validation checks WASM before acceptance.
WASM Artifact
Section titled “WASM Artifact”Check the executable result before execution:
| Boundary | Evidence to inspect |
|---|---|
| Interface | Expected exports, unauthorized imports and ABI compatibility. |
| Execution | Memory assumptions and primitive usage. |
| Provenance | Binary hash and 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;
- references to static validation evidence;
- referenced Binary Contract version;
- compiler or generator metadata;
- the path of the separate validation report;
- drift details when the artifact does not match the contract.
The current static validator checks artifact digests, contract and generation provenance, import allowlists, the declared entrypoint export and the absence of WASI. It does not by itself prove every possible ABI layout or runtime memory behavior. The Rust executor separately links host imports, requires the handler signature () -> i32 and applies configured memory and execution limits.
Runtime Acceptance
Section titled “Runtime Acceptance”The selected executor 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.
The deployment must also match the edition: Core executes in a container alongside Host and Config on the same host, without dedicated execution isolation. Pro executes through COS2000 in a KubeVirt VM under Kubernetes. Record the executor version and validate its supported imports and ABI; successful compilation alone does not prove compatibility.
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.