01 — Foundation
Constraints
Constraints are the enforcement mechanism for axioms and invariants. They are declared in the IDL schema, evaluated by the compiler during the appropriate phase, and surfaced as structured errors or warnings at build time. Constraints are not guidelines — a violated constraint produces a non-zero compiler exit code and blocks artifact generation.
Constraint Declaration
Constraints are declared alongside the schema elements they govern. A token-tier constraint is declared in the token schema. A composition constraint is declared in the component schema. This co-location ensures that the constraint travels with the schema element across versions and is not silently dropped when a schema element is modified.
Constraint Evaluation Phases
| Phase | Constraint Type | Output |
|---|---|---|
| Parse | Structural — grammar, module declaration, import cycles | Hard error, no AST produced |
| Transform | Semantic — token references, alias chains, slot graphs, state machines | Error or warning with source location |
| Emit | Behavioral — platform representability, tolerance bounds | Error blocks artifact; warning allows artifact with annotation |
Error vs. Warning Classification
Constraints are classified as either errors or warnings in their declaration. An error constraint, if violated, terminates the relevant compiler phase and produces exit code 2. A warning constraint, if violated, annotates the output and produces exit code 1 but does not terminate the phase. No constraint may be silently suppressed without an explicit governance-approved suppression mechanism.
Runtime Constraint Violations
Constraints are evaluated at build time, not at runtime. A construct that passes all build-time constraints is considered conformant. If a platform implementation produces incorrect output from a conformant IDL input, this is classified as an implementation failure, not a constraint violation. Implementation failures are reported against the emitter, not the specification.