Shaper OS · the fractal
Customisable client spaces, a fractal organisation
A shop, a client, a SaaS, a whole fleet: the same shape at every scale. That is what lets many universes be born, maintained and repaired with the same gestures, and gives every client the same command over their own.
Fractals in nature
AI-generated illustrations inspired by natural forms.
Similar forms reappear at different scales. This idea inspires SHAPER: units compose a universe, universes compose a space, and the same organisational logic extends through the tree.
Tree
A fractal
Fern
A fractal
Romanesco
A fractal
One shop, one universe
Consider an example: an online shop service where each client shapes their own space.
Each shop has its own universe. It brings together the functional units needed for its activity, each with its own database. Secrets, data and agents remain within their assigned scope.
Separate shops
Separating data, secrets and agents limits the spread of problems between shops.
A clean restoration
A shop is rebuilt from its description and the backup of its data, without touching its neighbours.
An agent dedicated to the shop
The agent works within its shop’s scope, with the information and permissions needed for its task.
The same foundation everywhere
Shops share organisational and management conventions. Their functional units, settings and dependencies adapt to the technology and business need.
The client steers their fractal with Helm
A client space brings together the universes of one entity: Helm, shop management, telephony or other services chosen for its needs. Through Helm, the team can steer these universes and act on them within its jurisdiction and each person’s permissions. Tools can be used separately or together.
Their jurisdiction
The universes, data and operations under the client’s responsibility, with permissions adapted to each person.
Outside their jurisdiction
The machines, the organs that build, the reference images, the other clients.
Guided onboarding
You learn to use Helm progressively, with approval for operations that require it.
The client’s fractal
They do with their shops what we do with our machines: decide, observe, correct, within their scope.
Who manages whom
Swipe to see the whole diagram
Never saw off the branch you are sitting on
A design rule, not a feature to tick.
Deep changes to a universe go through its parent, from outside. Its components can still be maintained within its mandate. At each scale, the responsible actor requests changes, the governor maintains desired state and makers carry out authorised operations. Helm lets the client request and follow changes to their universes without intervening in the foundation that keeps Helm running.
If the need touches the common model of all shops, it goes up to those who build it: a new version is proven, then each shop moves to it by decision, with a backup before and evidence after. A client who requires a different foundation gets their own variant.
The parent changes the child
Swipe to see the whole diagram
A SaaS that builds and maintains
The governor coordinates; makers carry out work on the machines.
The SaaS acts as a governor: it maintains the registry of what should exist for each client, according to approved orders and service rules. On each machine, a maker consults that registry, carries out authorised operations and reports results. It deploys universes from reference images prepared in advance, with client-specific configuration.
When a client pays
A line is written; the maker of the chosen machine reads it; the universe is born with the client’s specialisation and brand; the maker reports a verified fact, never a bare « done »; the client can steer this universe and act on it through Helm, within their jurisdiction.
Two views of the same system
On one side, the governor maintains desired state and makers carry out operations. On the other, universes are distributed across machines. These two views are independent.
The two shapes of universe
A universe can run in a system container or a Podman structure managed with PodMesh. Replication, backups and recovery rules are configured for continuity needs.
Two views of the same system
Swipe to see the whole diagram
Maintenance, where the power is
Evolve universes while retaining control over changes.
One fix, the whole fleet
The model is fixed, the new version is proven, and each universe moves to it by decision.
Nothing moves on its own
A new reference image does not automatically replace running universes: each update follows a decision and a recovery procedure.
Each repairs at its own level
Inside a universe, its components are repaired; birth and end come from the maker; the parent checks the child.
Silence is an event
A machine that stops reporting raises an alert, never a green light.
Backups kept separately
The backup server retrieves authorised copies and keeps them separate from active universes.
Growing without ceremony
Adding a machine means adding a maker; adding a product means adding a model, without touching the machines.
Several SaaS, one fleet
Each product sold has its own registry: shops, telephony, demonstration, and others tomorrow. The machines stay shared, and on each one a single maker serves every registry. The maker applies an approved description: the image address, its digest and the deployment recipe. A new SaaS therefore needs no new robot. One client can steer, in a single Helm, universes that come from several SaaS.
The demonstration works the same way: a visitor signs up, a demonstration universe is born for them, and at its end date it is destroyed, with proof of its absence. Learning takes place in a demonstration space separate from production.
What we promise
The method, not the stopwatch. Every level follows the same order, with clear steps and recovery planned. Together, we examine what can meet your needs and what still needs testing.
Several shops, sites or teams to steer?
Let us discuss your organisation, the universes you need and how to steer them together.