Skip to content

Plugin Architecture

VirtualForge is designed to be extended rather than rewritten. New capability arrives as a plugin — added without modifying core platform code, released on its own schedule, and isolated so that it cannot destabilize anything else.

This page describes how that works, what it means for you, and — because the honest answer matters more than the ambitious one — which parts exist today and which are still ahead.

Why not just build everything into the platform

The alternative is a platform that natively supports every data source, protocol, and integration pattern anyone might need. It sounds appealing and it fails predictably: the core grows without bound, every customer-specific requirement becomes a core change, and the release that adds support for your system also carries risk for everyone else's.

A plugin model splits the problem:

  • Capability is added without a platform release, by EEI or eventually by a third party.
  • A customer-specific integration does not require forking the platform.
  • Each extension has its own lifecycle — its own versioning, deployment, and updates.
  • Capability becomes discoverable and distributable, which is what makes a catalog possible.

Isolation is structural

Plugins do not share process space with core platform services. They communicate with the platform by message, run under their own identity, and hold only the access they need.

That is a design choice with consequences you can rely on:

Property What it means for you
Failure containment A misbehaving plugin cannot crash core platform services
Independent deployment Plugins are deployed, updated, and removed without restarting the platform
Least privilege A plugin can reach only what it is authorized to reach, and authenticates before it can participate
No shared execution Plugin code never runs inside core service processes — the isolation is architectural, not a policy someone has to remember to enforce

Plugins announce themselves when they start, declaring what they produce and consume; the platform validates their identity and authorization, monitors their health, and removes them from routing when they shut down. Version compatibility is tracked, so the platform can refuse a combination that would not work.

Plugin categories

Four kinds, matching the Tool categories:

Category Role Examples
Connector Brings data in from an external source Historians, industrial protocols, REST APIs, enterprise systems
Processor Transforms or enriches data in a stream Unit conversion, normalization, filtering
Output Delivers data to an external destination Webhooks, external databases, cloud services
Auth provider Adds an authentication method Directory services, single sign-on

How capability is packaged

The unit of contribution is a Category Manager and its Tools.

A Category Manager owns a category of capability and the shared behavior within it. A Tool is a specific unit of capability inside that category. Building new capability means either creating a new Category Manager together with its first Tool, or — more often — adding a Tool to a Category Manager that already exists.

The reason this matters to a customer rather than only to an engineer: it is what keeps the tenth tool in a category as reliable as the first. Shared behavior lives in one place and is inherited, so each new Tool is a small, well-bounded addition rather than a fresh opportunity to get the hard parts wrong. Connectors ++ is the same principle applied to Seeq connectors, and it is why we can add a connector quickly without lowering the bar.

The contribution path

The intended flow, end to end:

  1. Build a Category Manager and/or Tool against the platform's plugin interface.
  2. Package it for distribution.
  3. Submit the package through VirtualForge's submission flow.
  4. Go live on acceptance — the contribution becomes available on the platform.
  5. Commercial and legal terms are layered on: entitlements, licensing, review and certification where required.

Where this actually stands. The plugin interface and the plugin model exist and are in use today — this is how EEI builds and deploys its own tools. Automated packaging, self-service submission, the go-live pipeline, and the third-party commercial and legal framework are planned. They are described here to show direction; details, naming, and availability may change, and nothing here is a commitment to deliver a specific feature on a specific date.

Why an outside author would want this

The contribution path is not only a convenience for EEI. For someone who owns a valuable algorithm or method, building it as a Tool answers two problems at once.

Distribution without becoming a software company. Before anyone can buy an algorithm, somebody has to build and run the software around it — hosting, authentication, entitlement, metering, versioning, support, and a delivery surface. That work is unavoidable, undifferentiating, and the usual reason valuable analytical work stays a consulting engagement instead of becoming a product. The platform supplies that layer.

A boundary around the implementation. A Tool runs on the platform; consumers invoke it and receive results. The implementation is not distributed into the environments that use it — which matters especially for interpreted code, where shipping the algorithm means shipping the source and a license can govern operation but not inspection.

The infrastructure is not the part you want to be good at. The obvious alternative is to build all of that yourself on a hyperscaler. AWS or Azure will rent you every primitive — compute, identity, metering, even a marketplace listing. What neither will do is be your integrator. You still choose the services, wire them together, secure them, operate them, and keep them current, and then keep doing that for as long as the product lives. That is a standing infrastructure competency, and for most authors of a valuable method it is a second job competing with the one they are actually good at.

VirtualForge is opinionated where a general-purpose cloud is neutral: the choices are already made, the operational maturity is already paid for, and what you bring is the Tool. Two things follow that a hyperscaler cannot sell you at any price:

  • The input data is already there. A cloud will host your algorithm. It will not connect it to a customer's historian, or give it a presence inside the application where a process engineer actually works. Industrial connectivity is EEI's entire business, so the genuinely hard half — getting real plant data to your algorithm, in context — is the half you do not have to solve.
  • Capability compounds rather than accumulates. Your Tool becomes reachable from every connector already on the platform, and each connector added later extends your reach without either of us doing anything. On a general-purpose cloud you are one tenant among millions; here you are part of a portfolio that grows around you.

And a relationship, rather than a support tier. This is the part that does not fit in a feature comparison, so plainly: a hyperscaler sells capacity, and your success is not really its concern. We take the opposite view, and our values are the reason rather than the marketing — win-win in all matters, together we are stronger, and a code that includes ride for the brand and when you make a promise, keep it. Once your Tool is on the platform, our futures are joined: it is in our own direct interest that it succeeds, sells, and keeps working, because it has become part of what we are selling too. What you get is people who know the domain and answer the phone, not a ticket queue and a status page.

When a hyperscaler is the better answer. If you already have the infrastructure skill, your algorithm does not need industrial data in context, and you want to own the whole stack — build it there. We would rather say so in the first conversation than win an argument you come to regret.

This is what the commercial layer of the contribution path exists to support: entitlements, licensing, and revenue terms are how an outside author's Tool becomes something a customer can subscribe to. The fuller argument, from both the author's and the consumer's side, is in Algorithms as Tools; the commercial shapes an arrangement can take — design partner, cost-shared co-development, Tool subscription, engineering services — are in Bring Your Algorithm to the Forge.

If you are that author — you own working code and want it delivered as an API-based product — Bring Your Algorithm to the Forge covers what it would mean in practice: what the platform supplies, what you would need to bring, and how an arrangement between us could be structured.

Internal first, then open

The sequencing is intentional. The plugin model is proving itself on EEI's own tools before it is opened to anyone else, because an extensibility story that has not survived real use is a liability rather than a feature. Building our own products through the same path we would ask a partner to use is the only honest way to find out whether it is good enough.

From there, the direction is outward — first-party plugins, then trusted partners, then a broader ecosystem, as capital and market demand justify each step:

  • A catalog for discovering available capability.
  • Certification for EEI-validated third-party plugins, so "it works" is something we have checked rather than something you hope.
  • Multi-language support for building plugins.
  • Per-plugin entitlement and metering, so capability can be licensed cleanly.

The strategic intent is to grow VirtualForge from a set of EEI plugins into an open, extensible ecosystem over time — with the platform's capability surface expanding faster than any single company could manage alone.