One Pattern for Every Integration

i26g depends on three kinds of things it does not control: the infrastructure it runs on, the broker it trades through, and the sources its market data comes from. Each varies from one trader to the next, and each can fail in ways that matter. Instead of solving that three times, i26g uses one pattern for all of them.

The Problem Is the Same Every Time

Every external dependency raises the same questions. How does i26g use it without being written for one provider? How do you know a new provider will meet the same contract as the old one? And how do you stay in control of exactly which code talks to it?

Writing directly against one provider’s API answers none of them. A facade service in front of the providers answers some, at the cost of another system to run. i26g combines adapters with published contracts, shared tests, and explicit version control to answer all three.

The Shared Model

Every family of adapters — infrastructure, broker, and data — follows the same model:

1. A published interface. The capabilities i26g needs from that kind of dependency, each with fixed inputs and outputs, split into required and optional.
2. Conformance tests. Every adapter must pass the same tests before it counts as valid, whoever wrote it.
3. Versions. The interface is versioned, and each adapter declares which version it implements.
4. A tested set. The adapters for each family are delivered with i26g as a versioned set, tested against each release.
5. Pinning and verification. For each family, you pin the adapter-set version you run. i26g fetches that set, verifies its integrity, and checks compatibility with the interface version it expects. If either check fails, startup stops. Upgrades are your decision.

The Interface Between i26g and Your Infrastructure walks through the model in detail for infrastructure.

Where the Families Differ

The model is shared; the consequences of failure are not. Infrastructure changes can disrupt trading, broker errors can place unintended orders, and a broken data adapter can make a strategy act on incorrect or stale data. Each family therefore adds its own rules.

Broker Adapters

• Retries do not create duplicate orders. Submission uses a stable order identifier. If a request times out, the platform resolves its status before retrying that submission.
• Reconciliation comes before trading. After a restart or a lost connection, the platform checks its own record of orders and positions against the broker before it acts again.
• Tests never touch real money. Conformance tests run against paper-trading or sandbox accounts.

Data Adapters

• One time standard. Each source’s time zone and timestamp convention is made explicit and converted.
• Gaps and corrections are reported, not silently filled or overwritten.
• Freshness is exposed, so the i26g Control Plane can pause a strategy rather than let it act on stale data.
• Tests use recorded data with known gaps, corrections, and edge cases.

Infrastructure Adapters

• Capabilities stay inside the boundary. Adapters create VMs, networks, storage, and DNS only within the boundary the control plane is given.
• Provider-specific features are exposed as optional capabilities, so the control plane works with what each provider offers.

What You Get

One way of working for every integration. If you know how an infrastructure adapter is pinned, tested, and upgraded, you know how a broker or data adapter is. A new provider that fits the published interface can be added through an adapter that passes the same tests, without changing the platform. And the code that acts on your infrastructure, your money, and your data is always the code you chose.