i26g Control Plane

The Vision

A trading platform is not finished when it is deployed. Strategies change, data sources change, brokers change their interfaces, and the platform itself is extended as the trader’s edge develops. Every one of those changes is a chance for the running system to drift away from what it is supposed to do.

The i26g Control Plane runs the i26g Platform through its whole life cycle: from the first design decision, through building, releasing, and operating it, to changing it and eventually retiring parts of it. It also manages the environment the platform runs in — the VMs, networks, and storage inside the boundary it is given. Its desired state is declared in Git, and the control plane keeps what is running aligned with it — continuously, not just at the moment something is deployed.

Why This Is Needed

Operating a self-hosted platform well usually means assembling many separate tools: one for releases, one for configuration, one for observability, one for backups, and some process for deciding which changes go live. Each may be good at its part. What is missing is one coherent loop that runs across all of them — and coverage for the concerns nobody has got around to yet.

For a trading operation, that gap is expensive. A strategy that runs against stale data, a release that silently changes risk limits, or a broker integration that degrades without anyone noticing can all cost real money before anyone looks.

How It Works

The control plane is built around one loop — observe, orient, decide, act — applied to the platform as a whole rather than to any single component or tool:

Observe. Collect what the platform is actually doing: deployed versions, data freshness, strategy behaviour, execution quality, broker health, and resource use.

Orient. Compare that against what is declared in Git: configuration, risk limits, release history, and operating rules.

Decide. Determine what needs to change — a release to promote, a deviation to correct, a strategy to pause — following explicit, recorded rules rather than ad hoc judgement.

Act. Carry out the change through the same declared, reviewable path every time, and record what was done and why.

The loop does not switch on once the platform reaches production. It applies from the first line of code: changes are validated in isolated environments, promoted in a controlled order, and checked again once they run.

From Boundary to Running Platform

A trading operation cannot take its foundation on trust. Too little memory, a shared network, missing backups, or a clock that drifts can all break it quietly. So the i26g Control Plane does not assume its preconditions; it is given a boundary and checks it.

1. The boundary is set. Whoever runs the infrastructure creates a resource pool, a network zone and IP range, storage of a fixed size, and credentials scoped to exactly that boundary.
2. The control plane is bootstrapped. One VM is created in the pool and booted from the i26g Control Plane image.
3. It takes over. It checks the boundary against i26g’s infrastructure contract — the resources, isolation, and access it requires — and refuses to proceed if anything is missing. From then on it creates and manages everything inside: VMs, networks within the zone, storage, and the platform itself. It keeps checking the contract while the platform runs.
4. The boundary stays with its owner. Changing the boundary, repairing the control plane’s own VM, or revoking its credentials remains the infrastructure owner’s job, so a broken control plane can always be fixed from outside. The control plane monitors both, and when it needs more or different resources, it asks for them — for example as a proposed change to the infrastructure repository — and the owner decides.

How It Fits

The i26g Control Plane runs the i26g Platform, and the platform does the trading. Underneath, it needs only a boundary on generic infrastructure — a resource pool on premises, or a project in the cloud — and it does not depend on any particular way of providing it. Your infrastructure stays yours to choose and run; the trading environment inside the boundary belongs to i26g.

It is the life cycle thinking I apply as a solution architect, made concrete for one specific platform — specific enough to be built, rather than general enough to describe any solution.