LLM Boundaries

LLM Boundaries

sigMAXLLMgenerationcontrolled generationdeterministic toolingfinal code boundary

LLMs are useful in sigMAX because they can transform intent into structured material: architecture drafts, contracts, component descriptions, binary contracts, controlled pseudo-code and documentation.

They are not trusted as unchecked producers of final runtime artifacts. The boundary is deliberate: the LLM may propose structured intent and controlled logic, while deterministic tooling parses, validates, lowers, compiles, packages and records the effective state.

Core boundary

The LLM describes what should be produced. Contracts define what is allowed. Deterministic tooling produces executable artifacts. Agreements record what was actually produced.

Why The Boundary Exists

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.

What The LLM May Produce

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.1 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.

Good LLM output

Good output is boring in the best way: structured, parseable, tied to contracts, explicit about names, and easy for a validator to reject when it crosses a boundary.

What The LLM Must Not Own

The LLM should not be the authority for runtime behavior.

Not owned by the LLM	Why
Final C subset code	It must be produced by deterministic lowering from validated pseudo-code.
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.
Docker Compose output	The local stack is generated from skeletons and component inventory.
Agreements	Agreements record observed state after generation and validation.
Security exposure	Network, secrets, HTTP targets and native access require explicit policy.

No direct final code

A generated handler that jumps straight from prompt to unchecked C, WASM, SQL, sockets, filesystem calls or process APIs breaks the sigMAX trust model.

Runtime-Aware Prompt Contract

The current runtime generator makes the LLM boundary concrete. The pseudocode provider asks for sigmax.pseudo/v0.1 text only, with metadata lines, two-letter uppercase DSL instructions and explicit @... pseudo aliases. It rejects JSON, YAML, Markdown, code fences and C as generated output for this step.

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

Prompt rule	Boundary enforced
Generate pseudo-code text only.	Prevents accidental Markdown, YAML, JSON or C from becoming trusted input.
Start with #S, #M, #F and optional metadata.	Makes the artifact versioned and attributable.
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.

Primitive And Capability Rules

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.
Include only /runtime/sigma.h.	Generated C cannot pull in arbitrary headers.
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 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.

Runtime defaults

Pure helpers can be preferred for validation and transformation. Host primitives are used only when explicitly declared. Time and random are denied by default unless the contract allows them. HTTP targets are logical names, not arbitrary URLs.

Error And Success Shape

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.

Handoff Gates

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.1 or uses unknown instructions.
Primitive validation	A pseudo-code instruction requires an undeclared import or capability.
C subset generation	The pseudo-code cannot lower deterministically.
WASM validation	Imports, exports, ABI, memory assumptions or forbidden tokens drift.
Agreement comparison	The observed artifact differs from the expected contract state.

Reject, do not patch silently

When an output crosses the boundary, the safe response is to reject it with evidence. Silently editing generated artifacts after validation hides drift and makes the next run harder to trust.

Review Checklist

• 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?

Practical Rule

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.

https://sigmax.dev/docs/generation/llm-boundaries/