Storage Service
Storage Service
Section titled “Storage Service”Storage should be declared rather than hardcoded.
In sigMAX, application logic should not embed database-specific details directly inside generated WASM modules. Storage access is described through configuration and contracts, then exposed through controlled runtime primitives or internal service calls.
The storage service acts as an internal boundary between generated components and the concrete persistence layer.
It can:
- expose generic storage operations to the runtime;
- enforce allowed collections, object types, indexes and permissions;
- keep database-specific behavior outside WASM modules;
- provide a stable surface for local execution;
- record effective storage metadata in agreements;
- support drift detection when generated storage artifacts differ from the declared model.
The goal is not to hide storage completely. The goal is to make storage behavior explicit, auditable and bounded.
storage.yaml
Section titled “storage.yaml”storage.yaml can describe the expected storage surface for a generated application or component.
It may define:
- logical storage areas;
- collections or object types;
- field definitions and indexes;
- read, write, list, update or delete permissions;
- validation rules;
- ownership or tenant boundaries;
- generated initialization artifacts;
- allowed runtime operations;
- links to the contracts that require the storage surface.
The file should describe what the application needs, not leak arbitrary implementation details into business code.
Runtime Flow
Section titled “Runtime Flow”The runtime keeps storage access inside a controlled path.
Generic Operations
Section titled “Generic Operations”Storage operations should remain generic at the runtime boundary.
Typical operations include:
| Operation | Purpose |
|---|---|
get | Read one object by key or identifier. |
list | Read a bounded collection with filters or pagination. |
create | Insert a new object that satisfies the declared schema. |
update | Modify an existing object through an allowed operation. |
delete | Remove an object when the contract allows deletion. |
query | Execute a constrained, declared query shape. |
These are logical operations. They do not mean WASM modules can issue arbitrary SQL or reach the database directly.
Contracts And Agreements
Section titled “Contracts And Agreements”The storage declaration belongs to the expected state. The generated or prepared storage result belongs to the effective state.
| Layer | Expected state | Effective evidence |
|---|---|---|
| Contract | Required storage capabilities and constraints. | Linked contract version. |
storage.yaml | Collections, object types, permissions and indexes. | Generated or resolved storage configuration. |
| Runtime | Allowed storage primitives and route capabilities. | Runtime validation result. |
| Storage service | Internal adapter behavior. | Initialized schema, generated artifacts, hashes or metadata. |
This separation is important because storage drift can be subtle. A generated component may still run even when an index, permission or collection differs from the expected model.
Core And Enterprise
Section titled “Core And Enterprise”In sigMAX Core, storage is part of the controlled local runtime surface. It should remain simple, inspectable and self-managed.
Core can document the expected storage behavior and expose generic storage operations, but it should not be presented as a platform with many interchangeable storage products.
sigMAX Enterprise can extend the storage environment when needed:
- object storage such as MinIO;
- Redis or other supporting databases;
- managed database provisioning;
- backup and retention policies;
- Kubernetes storage classes;
- governance and approval workflows around schema changes.
These additions should not change the contract-first principle. They extend the operational environment around the same expected/effective validation loop.
Drift Examples
Section titled “Drift Examples”Storage drift can appear when:
- a collection exists in the effective configuration but not in the contract;
- a required index was not generated;
- a route can perform a write operation that was not declared;
- a WASM module calls a storage primitive without the required capability;
- initialization artifacts differ from the recorded agreement;
- an Enterprise deployment adds a storage backend that is not represented in the expected topology.
Design Rules
Section titled “Design Rules”A good storage model should be:
- declarative before execution;
- generic at the WASM boundary;
- explicit about permissions;
- strict about route capabilities;
- inspectable through agreements;
- conservative in Core;
- extensible in Enterprise without hiding infrastructure drift.