Skip to content

· the fractal

A management fractal, and clients who manage in a fractal themselves

A shop, a client, a , 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.

One shop, one universe

In development · designed

The shop models are not built yet; the common foundation is measured in the lab.

Each shop lives in its own universe: a that carries everything it needs, and nothing for the others. Its secrets, its database, its evidence and its belong to it alone.

No domino effect

If one shop goes down, the others carry on: they share no secrets, no database, no .

A clean restoration

A shop is rebuilt from its description and the backup of its data, without touching its neighbours.

An that sees only its shop

The shop’s knows only that shop: it is never polluted by the rest.

The same foundation everywhere

Between a WordPress shop and a PrestaShop shop, only the business brick changes.

The client steers their fractal with Helm

In development · designed

The client has their own Helm universe. That universe steers a « shop manager » universe, connected to their shops, up to five in the offer we have in mind. The whole team talks to Helm, in writing from their workspace or by voice from their phone system, each at their own level.

Their jurisdiction

Full power over their universes, down to their smallest components.

Outside their jurisdiction

The machines, the organs that build, the reference images, the other clients.

Levels proven, not declared

Each person progresses through guided missions, with no traps: what Helm carries out directly depends on the level they have shown; beyond it, Helm prepares and has it approved.

The client’s fractal

They do with their shops what we do with our machines: decide, observe, correct, within their scope.

Diagram

Who manages whom

Who manages whommaster rootbuilding organsfleetevery SaaSa shop SaaSkeeps the registryanother SaaStelephonyanother SaaSdemonstrationa client: its jurisdictionHelm universethe client’s team steers hereshop managershopshopshopfree slotfree slotup to five shops in the imagined offereach box is the parent of the one it contains

Swipe to see the whole diagram

This nesting is the nesting of management, not of machines: one client’s universes can run on several machines.

Never saw off the branch you are sitting on

A design rule, not a feature to tick.

A universe never changes how it works while it is running. The deep changes of a child are always made by its parent, from outside: the human and tandem in charge of the root universe changes and repairs it; the root universe, which carries the building organs, gives birth to the client’s Helm universe and repairs it; the Helm universe changes the shop manager; the shop manager changes each shop; a shop does its work, and that is all.

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.

Diagram

The parent changes the child

The parent changes the childthe human and agent tandemof the root universechanges and repairs, from outsidethe root universebuilding organschanges and repairs, from outsidethe client’s Helm universechanges and repairs, from outsidethe shop managerchanges and repairs, from outsidea shopdoes its work, and that is alla universe neverchanges how it workswhile it is running

Swipe to see the whole diagram

Each rung changes and repairs the one below, from outside. Nobody changes themselves while running.

A that builds and maintains

In development · measured in the lab

The full chain, from sign-up to the birth of a universe, worked end to end once, in a demonstration environment. Pausing and deployment with PodMesh are designed only.

Each keeps a registry of what must exist, client by client. According to billing, it enters the universes to create, destroy or pause. On each machine, a maker, the hand of the machine, asks what there is to do, gives birth to or ends universes, and reports what it found. Reference images are prepared in advance: a universe is born from an image that is already ready, it is not installed.

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 universe appears in the client’s Helm.

Two views of the same system

Who decides (the registry, then the makers) and where it runs (universes side by side on several machines). Management does not follow location.

The two shapes of universe

A classic system , or a universe deployed with PodMesh, which enrols it in the cluster’s continuity and recovery plan.

Diagram

Two views of the same system

Two views of the same systemwho decidesregistryone per SaaSwhat must exist, according to billingcreatedestroypauseasks / repliesmakermachine 1makermachine 2makermachine 3no open portwhere it runsmachine 1machine 2machine 3the universes of one clientmanagement does not follow location

Swipe to see the whole diagram

On the left, who decides: the registry says what must exist, the makers ask it and report what they found. On the right, where it runs: one client’s universes are spread across several machines.

Maintenance, where the power is

Design principles, not delivered features.

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 live universe stays on the version it was born from: improving the model never breaks a client .

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 are pulled

The vault fetches the copies; it listens to no one.

Growing without ceremony

Adding a machine means adding a maker; adding a product means adding a model, without touching the machines.

Several , one fleet

In development · designed

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 does not know what it builds: it reads an address, a fingerprint and a recipe. A new therefore needs no new robot. One client can steer, in a single Helm, universes that come from several .

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. The gesture is learnt where a mistake costs nothing.

What we promise

The method, not the stopwatch. Every level follows the same order, with no hidden state and no manual gesture; what is not proven yet is marked as such on this page.

Several shops, sites or teams to steer?

Let us talk about what you want to steer, and about what is already proven today: every status on this page says where reality stands.