LLMs shape intent into architecture drafts, contracts, component descriptions, binary contracts, controlled pseudo-code and documentation. They do not have unchecked authority over final runtime artifacts.

Uncontrolled generation can drift silently. A model can invent a helper, skip a validation step, add an import, choose an undeclared HTTP target, or produce code that looks plausible but no longer matches the declared architecture.

sigMAX avoids that failure mode by placing the LLM before the executable boundary. The model works in formats that can be checked, rejected and regenerated without granting runtime authority.

Risk	sigMAX response
Invented implementation detail	Require contracts, declared primitives and known DSL instructions.
Hidden host access	Allow only imports and capabilities listed in the Binary Contract.
Unbounded payload or parsing	Use runtime primitives with documented limits.
Drifting architecture	Compare contracts with generated agreements.
Plausible but invalid output	Parse and validate before lowering or execution.

The LLM can help in stages where ambiguity still needs to be shaped into explicit structure.

Area	Acceptable LLM contribution	Required handoff
Architecture	Identify domains, components, routes and boundaries.	Application and Component Contracts.
Contracts	Draft structured expected state.	Schema validation and contract review.
Binary behavior	Describe handler inputs, outputs, imports and constraints.	Binary Contract validation.
Controlled logic	Generate sigmax.pseudo/v0.3 pseudo-code.	Pseudocode parser and deterministic lowering.
Documentation	Explain generated artifacts and validation results.	Human review and source alignment.
Tests	Draft scenarios from declared routes and contracts.	Deterministic test generation or explicit fixtures.

The LLM should not be the authority for runtime behavior.

Not owned by the LLM	Why
Final C subset or MoonBit code	It must be produced by deterministic lowering from a validated AST.
WASM artifacts	They must be compiled and checked by the toolchain.
Runtime imports	Imports must come from declared primitives and binary contracts.
Capabilities	Host access must be declared, not inferred by generated prose.
Deployment output	Current topology tooling manages application containers through the Engine API. Core Compose packaging and Pro Kubernetes/KubeVirt resources must come from the validated release distribution.
Agreements	Deterministic code records artifact state; separate validation reports establish which checks passed.
Security exposure	Network, secrets, HTTP targets and native access require explicit policy.

The current Rust compiler in studio/tools/pseudocode-compiler/ parses versioned pseudo-code into an AST and generates C subset or MoonBit source. Generation prompts should request the supported DSL, including its metadata, instructions and declared primitive aliases. The parser and contract checks determine acceptance; prompt wording is not an enforcement mechanism.

That keeps the LLM output narrow enough to parse before any executable artifact exists.

Prompt rule	Boundary enforced
Generate the supported pseudo-code artifact.	Keeps prose or unrelated source code out of the compiler input.
Supply required #S, #M, #F, #C, #D and #V toon: metadata in order.	Makes the artifact versioned and attributable, and allows checks against the contract and catalogue.
Use two-letter DSL instructions.	Keeps operations inside the parser vocabulary.
Use only contract fields, bindings and outputs.	Prevents invented data paths.
Use only primitives documented in runtime/functions.toon.	Prevents invented host imports.
Do not write raw C calls.	Keeps C generation deterministic.

The runtime primitive catalog is the vocabulary the LLM must respect.

Rule	Meaning for generation
Use only declared sigMAX primitives.	Unknown primitive names are generation errors.
Use the declared runtime bindings.	C uses runtime/C/sigma.h; MoonBit uses runtime/moonbit.
Direct Linux calls are forbidden.	No raw filesystem, sockets, process APIs or syscalls.
Direct SQL is forbidden.	Storage goes through declared bindings and runtime primitives.
Raw JSON responses are forbidden.	Public responses use response and ObjectIR primitives.
Host primitives require their listed capabilities.	HTTP, storage, time, random, regex, JSON and secrets stay policy-controlled.
WASM imports must be listed.	A primitive with a wasm_import must appear in the Binary Contract.
Capabilities must be listed.	A primitive with a capability must be allowed by contract.

The LLM must preserve the runtime control shape expected by deterministic lowering.

Case	Required shape
Validation failure	Set response status, emit validation error, return -1.
Runtime/API error	Set response status, emit structured error, return -1.
Success	Set response status, build ObjectIR output, return 0.
Storage/service call	Use declared typed binding through the runtime primitive surface.
Input handling	Use only input primitives allowed by the Binary Contract.

This matters because the compiled WASM module is later checked against imports, exports, ABI assumptions, generated C and agreement evidence.

Each LLM-produced artifact should cross a gate before it becomes input to the next stage.

Gate	Reject when
Contract parsing	The output is not valid structured contract data.
Contract validation	Required routes, components, bindings or binary fields are missing.
Pseudo-code parsing	The file is not sigmax.pseudo/v0.3 or uses unknown instructions.
Primitive validation	A pseudo-code instruction requires an undeclared import or capability.
Source generation	The AST cannot lower deterministically to the selected C or MoonBit target.
WASM validation	Imports, exports, ABI, memory assumptions or forbidden tokens drift.
Agreement comparison	The observed artifact differs from the expected contract state.

• Does the generated output match the expected artifact type?
• Does it reference only contract-defined names?
• Are imports and capabilities declared before use?
• Are HTTP targets logical and policy-controlled?
• Are errors emitted with status, structured error and return -1?
• Are successful responses emitted through ObjectIR?
• Can the next deterministic tool parse it without guessing?
• Would an agreement be able to record and compare the result?

The generation boundary applies to both proprietary editions. Core deploys Host and Config together on one Docker Compose host, with WASM execution in a container and no dedicated execution isolation. Pro uses Kubernetes with COS2000 in a KubeVirt VM. Generation validation and VM isolation address different concerns; one does not establish the other.

Use the LLM where language, intent and decomposition are useful. Stop the LLM where executable authority begins.

That line is the main design choice: sigMAX can benefit from generation while keeping final code, runtime access, validation, packaging and drift evidence under deterministic control.