Contracts
Contracts
Section titled “Contracts”Contracts describe the expected system state before generation, validation, packaging or execution: components, binaries, boundaries, exposed capabilities, execution constraints and validation expectations. Generated artifacts and reports provide the evidence.
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.
Blue documents express the expected system; the green record groups produced artifacts and agreements; the amber control compares that evidence with the contracts. Recording an agreement and validating it are separate stages.
Execution placement follows the edition: the containerized runtime in Core or COS2000 in a KubeVirt VM in Pro. Static artifact evidence does not establish that a deployment has run successfully.
What A Contract Contains
Section titled “What A Contract Contains”Make assumptions visible before code or runtime artifacts exist.
Architecture & interfaces
- Names and stable identifiers.
- Responsibilities and dependencies.
- Routes, methods, inputs, outputs and endpoints.
- Health, documentation and discovery surfaces.
Execution & evidence
- Allowed primitives and capabilities.
- Security and isolation constraints.
- Binary imports, exports, memory layout and limits.
- Expected artifacts and expected/effective validation rules.
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.
Edition-Specific Deployment Constraints
Section titled “Edition-Specific Deployment Constraints”An Application Contract must identify the deployment target. Core uses Docker Compose with Host and Config on one host; WASM executes in a container without dedicated execution isolation. Pro uses Kubernetes and the COS2000 executor in a KubeVirt VM. Record the actual executor, artifact and network assumptions instead of inferring isolation from the WASM format.