Contracts
Contracts
Section titled “Contracts”Contracts describe the expected system state before generation, validation, packaging, or execution.
In sigMAX, a contract is not a log, not a generated artifact, and not runtime evidence. It is the structured description of what should exist: components, binaries, boundaries, exposed capabilities, execution constraints, and validation expectations.
Contract Levels
Section titled “Contract Levels”sigMAX uses several contract levels because one file cannot describe every boundary with the same precision.
| Level | Scope | Main responsibility |
|---|---|---|
| Application Contract | Full application architecture | Defines components, routes, exposure, dependencies, infrastructure expectations, and cross-component constraints. |
| Component Contract | One autonomous component | Defines the component surface, runtime endpoints, local capabilities, health, API exposure, and generated artifacts expected for that component. |
| Binary Contract | One executable WASM unit | Defines imports, exports, memory expectations, allowed primitives, input/output layout, and execution limits. |
These levels form a chain. The application contract decomposes into component contracts, and component contracts can reference one or more binary contracts.
What A Contract Contains
Section titled “What A Contract Contains”A contract is intentionally explicit. It should make important assumptions visible before code or runtime artifacts exist.
Typical contract content includes:
- names and stable identifiers;
- routes, methods, inputs, outputs, and exposed endpoints;
- component responsibilities and dependencies;
- allowed runtime primitives and capabilities;
- security and isolation constraints;
- expected generated artifacts;
- health, documentation, and discovery surfaces;
- binary imports, exports, memory layout, and limits;
- validation rules used to compare expected state with effective state.
Application Contract
Section titled “Application Contract”The Application Contract describes the global shape of the system.
It can define the expected application topology, component list, public exposure, internal dependencies, routing model, storage expectations, and operational constraints. It is the highest-level contract and should remain readable enough to explain what the generated system is meant to be.
An Application Contract should answer:
- which components exist;
- which routes or APIs are exposed;
- which dependencies exist between components;
- which runtime capabilities are allowed;
- which environment boundaries must remain internal;
- which artifacts must be produced for inspection.
Component Contract
Section titled “Component Contract”The Component Contract narrows the expected state to one deployable component.
It defines the component API surface, local runtime behavior, health and discovery endpoints, generated documentation, required binaries, and allowed primitives. A component may be independently deployable, but it is still governed by its contract.
This contract is useful because component-level validation can be performed without reinterpreting the whole application every time.
Binary Contract
Section titled “Binary Contract”The Binary Contract describes one executable WASM unit.
It is closer to the runtime boundary than the application or component contracts. It can define the WASM imports, exports, input and output layout, allowed primitive calls, memory limits, execution limits, and expected ABI shape.
The Binary Contract is especially important when deterministic tooling compiles controlled pseudo-code into WASM. The final executable can then be checked against the contract before it is trusted by the runtime.
Contracts And Agreements
Section titled “Contracts And Agreements”Contracts and agreements are paired, but they do not mean the same thing.
A contract describes what should happen. An agreement records what did happen after generation, compilation, packaging, or validation.
Design Rules
Section titled “Design Rules”A good contract should be:
- explicit enough to validate;
- stable enough to audit;
- scoped to the right level;
- readable by humans;
- precise about runtime capabilities;
- separate from generated evidence;
- strict about boundaries that must not be exposed accidentally.
The goal is not to write every implementation detail into the contract. The goal is to make the expected architecture, executable boundary, and validation surface clear before the system is generated or executed.