Introduction

Introduction

sigMAXintroductionarchitecturehexagonal architecturemicroservicescontract-firstgenerative driftengineering principles

What is sigMAX?

sigMAX means Secure Integrated Generator of Modular Architecture with eXecution runtime.

sigMAX is an AI-driven, contract-first application generation platform. It transforms a functional intent into formal contracts, then generates the associated components, APIs, WASM binaries, documentation, tests, and execution artifacts.

Business logic is not generated directly as unchecked free-form code by the LLM. It flows through controlled representations that are validated first, then transformed deterministically. This limits generative drift and makes it possible to verify that the produced system matches the declared expectations.

sigMAX is designed to produce modular, portable, observable, testable, and secure applications executed in a standardized runtime based on WebAssembly and containers.

The idea

Modern applications can follow very different architectural models. Each model has trade-offs between simplicity, maintainability, scalability and operational complexity.

sigMAX is designed to move generated applications toward a more maintainable, modular and verifiable architecture, without forcing developers to manually assemble every technical layer.

The target infrastructure model is hexagonal over microservices: domain boundaries come first, service deployment comes second. A component is created because it represents a meaningful contract-defined capability, not because every generated function must become an independent service.

This model is also explicit and contract-first. Intent is converted into application, component and binary contracts before runtime artifacts are produced. Those contracts describe the expected boundaries, exposed capabilities, allowed primitives, APIs, storage access and execution constraints.

This matters because microservices alone do not prevent coupling. If boundaries are unclear, generated services can still drift into a distributed monolith. sigMAX reduces that risk by comparing the declared target state with generated agreements, so architectural drift and generative drift can be detected instead of silently accumulating.

Architecture model	Simplicity	Maintainability	Typical issue
Monolith	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Simple at first, but difficult to evolve when the domain grows.
Modular	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Good compromise, but requires strict internal boundaries.
N-tier	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Clear layers, but coupling often leaks between UI, services and data.
SOA	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Service boundaries exist, but governance and contracts can become heavy.
Microservices	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Powerful decomposition, but operational complexity grows quickly.
Event-driven	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Scalable and decoupled, but harder to understand, test and operate.
Serverless	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Fast to deploy, but portability and runtime control can be limited.
Hexagonal	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Better separation of concerns, but requires discipline and structure.
sigMAX target model	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Uses contracts, components and WASM runtime to keep modularity explicit and verifiable.

sigMAX aims to keep the benefits of modular and hexagonal architectures while reducing their operational cost through generation, contracts, agreements and runtime standardization.

The goal is not only to generate code, but to generate an application structure.

The 12 engineering principles

sigMAX is built around twelve core engineering principles.
The idea is simple: when an application follows these principles by design, the result has a much higher chance of being robust, understandable, portable and maintainable.

• Maintainability — The system must remain understandable and easy to evolve over time.
  sigMAX: contracts, generated structure and agreements keep the architecture explicit.
• Idempotence — Running the same generation or deployment step multiple times should lead to the same expected state.
  sigMAX: generation steps are designed to be safely repeatable.
• Reproducibility — The same inputs should be able to produce the same outputs.
  sigMAX: inputs, contracts and generated artifacts are tracked and validated.
• Portability — The application should run across environments with minimal changes.
  sigMAX: components are packaged with containers and executed through WebAssembly.
• Observability — The system should expose logs, metrics, health status and runtime signals.
  sigMAX: the runtime standardizes logs, metrics, healthchecks and component status.
• Testability — Components, APIs and generated artifacts should be testable automatically.
  sigMAX: tests can be generated from contracts, routes and expected runtime behavior.
• Documentation — The system should generate and expose useful technical documentation.
  sigMAX: OpenAPI, component metadata and docs are generated with the application.
• Determinism — Critical generation steps should be deterministic and controlled.
  sigMAX: LLM output is transformed into controlled plans, then generated deterministically.
• Automation — Repetitive tasks should be scripted, generated or validated automatically.
  sigMAX: Make targets and generators automate contracts, artifacts, builds and validation.
• Security — Execution should be isolated, constrained and capability-oriented.
  sigMAX: WASM sandboxing, runtime primitives and contracts limit what code can do.
• Modularity — The application should be composed of clear, independent components.
  sigMAX: components are contract-defined, independently generated and discoverable.
• Immutability — Generated artifacts should be versioned and treated as stable outputs.
  sigMAX: contracts, agreements, WASM binaries and containers can be hashed and versioned.

Following these principles does not magically guarantee that an application is perfect.
But it strongly increases the probability that the generated result will be well-structured, verifiable, maintainable and production-ready.

In sigMAX, these principles are not only recommendations. They are progressively enforced through:

• contracts;
• agreements;
• deterministic generation;
• WebAssembly isolation;
• generated documentation;
• automated validation;
• reproducible containerized builds.

Hexagonal architecture over microservice architecture

sigMAX does not start from microservices as a default architectural choice.

Microservices are a deployment topology. Hexagonal architecture is a design discipline.

This distinction is important: splitting an application into many services does not automatically make it maintainable. Without clear boundaries, contracts, validation and observability, microservices can easily become a distributed monolith.

Core position

sigMAX favors hexagonal architecture first, then lets the generated components be deployed independently when it makes sense.

The goal is not to create more services.
The goal is to create better boundaries.

Why not microservices first?

Microservices are useful when the domain, organization and operational maturity justify them. But using microservices too early often introduces complexity before the application boundaries are clear.

Common issues include:

• too many small services with unclear responsibilities;
• duplicated infrastructure;
• network coupling instead of domain decoupling;
• inconsistent APIs;
• distributed debugging;
• harder local development;
• harder testing;
• more deployment coordination;
• hidden dependencies between services.

sigMAX tries to avoid this by generating applications from explicit contracts and component boundaries.

Hexagonal architecture as the default model

Hexagonal architecture separates the core business logic from the outside world.

The application is organized around:

• domain logic;
• ports;
• adapters;
• contracts;
• external systems;
• runtime boundaries.

In sigMAX, this maps naturally to:

Hexagonal concept	sigMAX equivalent
Domain core	WASM business binary
Port	Contract-defined capability
Adapter	Runtime primitive, storage binding, HTTP route or Dapr invocation
Input adapter	REST route, generated API endpoint or FrontMark UI action
Output adapter	Storage service, external HTTP call, event or ObjectIR response
Boundary	Component Contract
Runtime proof	Agreement

Microservices vs hexagonal components

Model	Primary goal	Strength	Risk
Microservices	Deploy independently	Scalability and organizational autonomy	Operational complexity and distributed coupling
Hexagonal architecture	Isolate domain logic	Maintainability and testability	Requires clear boundaries and discipline
sigMAX components	Generate verifiable boundaries	Contracts, WASM isolation and agreements	Requires a controlled generation pipeline

sigMAX components are not “microservices by default”. They are contract-defined units that can become services when required.

This gives more flexibility:

• a component can run locally in a generated compose stack;
• a component can expose REST endpoints;
• a component can call another component through Dapr;
• a component can later be deployed independently;
• a component can be validated before and after generation.

Component-first, service-second

sigMAX follows a component-first approach:

1. Domain boundary
2. Component Contract
3. Binary Contracts
4. WASM modules
5. Runtime container
6. Optional service exposure

The service is therefore a consequence of a clear component boundary, not the starting point.

Design rule

In sigMAX, a component should exist because it represents a meaningful domain or technical boundary, not because every function must become a service.

Comparison

Microservices-firstHexagonal-firstsigMAX approach

Split the system into services first, then try to stabilize contracts, APIs, tests and observability afterwards.

👍 Positive	👎 Negative
Independent deployment Team-level ownership Targeted scaling Technology isolation	Many repositories and APIs Many deployments Unclear ownership Network calls everywhere Difficult local development

Characteristics

Characteristic	Rating
Boundary clarity	⭐⭐☆☆☆
Operational simplicity	⭐☆☆☆☆
Independent deployment	⭐⭐⭐⭐⭐
Local development	⭐⭐☆☆☆
Testability	⭐⭐☆☆☆
Observability requirement	⭐⭐⭐⭐⭐

Define the domain boundary first, then expose it through adapters.

👍 Positive	👎 Negative
Isolated domain logic Easier tests Explicit dependencies Replaceable adapters Understandable architecture	Requires modeling discipline Boundaries can be subjective Needs shared vocabulary Deployment independence is not automatic

Characteristics

Characteristic	Rating
Boundary clarity	⭐⭐⭐⭐⭐
Operational simplicity	⭐⭐⭐⭐☆
Independent deployment	⭐⭐⭐☆☆
Local development	⭐⭐⭐⭐☆
Testability	⭐⭐⭐⭐⭐
Observability requirement	⭐⭐⭐☆☆

Generate the boundary as a contract, generate the component from the contract, compile business logic to WASM, then validate the result with agreements.

👍 Positive	👎 Negative
Contract-defined boundaries Less manual drift WASM isolation Agreement validation Portable components	Contracts must stay accurate Generation rules must be versioned Runtime primitives must be understood Validation becomes part of delivery

Characteristics

Characteristic	Rating
Boundary clarity	⭐⭐⭐⭐⭐
Operational simplicity	⭐⭐⭐⭐☆
Independent deployment	⭐⭐⭐⭐☆
Local development	⭐⭐⭐⭐☆
Testability	⭐⭐⭐⭐⭐
Observability requirement	⭐⭐⭐⭐☆

The sigMAX target

sigMAX aims to keep the benefits of hexagonal architecture while reducing the manual cost of applying it.

It does this through:

• Application Contracts;
• Component Contracts;
• Binary Contracts;
• generated routes;
• generated OpenAPI;
• generated storage bindings;
• controlled pseudo-code;
• deterministic C/WASM generation;
• runtime primitives;
• agreements;
• validation.

Summary

sigMAX does not reject microservices. It avoids making microservices the default starting point.

The preferred model is:

hexagonal boundaries first contract-defined components second service deployment only when useful

This helps generated applications remain:

• maintainable;
• modular;
• testable;
• observable;
• portable;
• secure;
• verifiable.

https://sigmax.dev/docs/