Generation Overview

Generation starts from intent and constraints, then creates structured artifacts.

sigMAX separates the generation flow into two parts. The LLM helps shape intent into explicit contracts and controlled pseudo-code. Deterministic tools parse pseudo-code into an AST, generate C subset or MoonBit source, and produce WASM artifacts and validation evidence. Deployment artifacts depend on the selected edition.

The important rule is simple: creative assistance stops before executable authority begins. Each stage leaves evidence that can be parsed, validated and compared against the expected contract state.

The diagram follows the current Studio generation toolchain. Packaging and execution are separate stages; it does not imply one container or one VM per component.

Slanted blue shapes carry inputs and intermediate data; the amber hexagon is a validation gate, the violet double border marks the compiler, and the green end shape is a recorded artifact. The binary agreement is created after compilation with validation pending. A separate binary.validate stage checks its evidence and writes a validation report; an agreement file alone does not mean acceptance.

COS2000 also provides a separate Radjae compiler path from validated pseudo-code directly to WASM. The C/MoonBit pipeline shown above does not describe Radjae; see the COS2000 executor.

Stage Responsibilities

Each stage owns a narrow responsibility. That separation is what keeps the generated result inspectable.

Stage	Main responsibility	Evidence
Intent	Capture what the application should do and which constraints matter.	Prompt context, project notes, architecture decisions.
Blueprint	Convert intent into a structured architectural plan.	Blueprint artifact and decomposition rationale.
Contracts	Declare the expected application, component and binary state.	Application, Component and Binary Contracts.
Controlled pseudo-code	Express executable intent without giving the LLM final code authority.	Pseudocode DSL files linked to Binary Contracts.
Deterministic generation	Parse DSL to AST, generate C subset or MoonBit, compile WASM and validate artifacts.	AST, generated files, hashes and compiler reports.
Agreements	Record produced artifacts, then validate their evidence separately.	Application, Component and Binary Agreements, plus validation reports.
Runtime	Execute validated WASM through declared primitives.	Health, logs, ObjectIR output, runtime checks.

Deployment Targets

Edition	Placement	WASM execution
Core	Docker Compose with Host and Config on one host.	In a container, without dedicated execution isolation.
Pro	Kubernetes.	COS2000 in a KubeVirt VM.

The compiler implementation is in studio/tools/pseudocode-compiler/; Studio’s topology service operates the current application containers through the Docker Engine API. The older Python sigmaxgen generator and Compose skeleton are not the current implementation. Generated artifacts must target the selected executor ABI, and Pro integration must be validated against the actual VM deployment.

Why The Split Matters

Creative shaping · LLM

Interpret intent and draft structured artifacts. LLM output is not trusted as final executable truth.

Executable production · toolchain

Deterministic generators and validators take over before compilation, packaging and runtime execution.

Expected state — what contracts say should exist.
Produced state — what generators actually created.
Observed state — what the running artifact exposes.

Differences between these checkpoints should become visible as drift.

Where To Continue

Topic	Next page
How pseudo-code is constrained	Pseudocode DSL
How C and WASM are produced	C/WASM Generation
How packaging and application topology differ	Core deployment and topology
What the LLM may and may not own	LLM Boundaries