Bring Your Algorithm to the Forge¶
This page is for you if you own working code and want it to become a product.
A method refined over years. A model trained on data nobody else has. A formula that encodes real domain judgment. It runs — on a laptop, in a notebook, inside a consulting engagement — and the thing standing between it and a customer who would pay for it is not the algorithm. It is everything around the algorithm.
VirtualForge is that everything. It exists so an algorithm can be delivered as an API-based product — invoked over the network, from the environment where the work actually happens, returning results — without its author first building and operating a software company.
You focus on the part only you can do. We supply the part that has to exist and differentiates nobody.
Status: planned, and being built toward. The platform, the Category Manager and Tool model, and the plugin SDK exist and are in use today — this is how EEI builds and deploys its own tools. A self-service path for outside authors does not exist yet: automated packaging, submission, certification, and the third-party commercial and legal framework are planned. This page describes where we are going and invites the conversation that shapes it. Nothing here commits EEI to a specific capability on a specific date.
What this actually looks like¶
Your algorithm becomes a Tool on VirtualForge.
A consumer — a process engineer in Seeq, an application, a scheduled job — invokes it. The platform authenticates the caller, checks they are entitled to it, runs your Tool, and returns the result into whatever they asked from. Your implementation stays on the platform. What crosses the boundary is the answer, not the method.
The unit of contribution is a Tool, and Tools live under a Category Manager that owns the shared behavior for a category of capability. So contributing means one of two things:
- A new Tool under an existing Category Manager — the common case, and the small one.
- A new Category Manager and its first Tool — where your work opens a category the platform does not have yet. A domain-specific one, for instance: the Category Manager holds what is common to a family of related Tools, and each Tool is a specific capability within it.
The mechanics of isolation, registration, and packaging are in plugin architecture. The argument for delivering analytical work this way, from both the author's and the consumer's side, is in Algorithms as Tools. This page is about what it would mean for you to do it, technically and commercially.
The technical side¶
What the platform supplies¶
This is the list of things that have to exist before anyone can buy your algorithm, and that you would otherwise build:
| The platform provides | Which means you do not build |
|---|---|
| Hosting and runtime | Somewhere for your code to run that stays running, scales, and gets patched |
| Identity and authentication | Deciding who is calling, and proving it |
| Entitlement | Granting, limiting, and revoking access per customer |
| Metering | Counting what was used, in a way a bill can be built from |
| Versioning and deployment | Shipping an improvement without breaking the people who depend on you |
| Delivery surfaces | The API, the Toolbox inside Seeq, the command line — the places a consumer reaches capability |
| Observability | Structured logs, health reporting, and diagnostics you can be paged from |
| Isolation | Your Tool cannot destabilize the platform, and the platform's other tenants cannot see into yours |
| A data layer | ForgeVault where your Tool needs state, history, or metadata alongside its compute |
| Connectivity | Getting the input data to your algorithm in the first place — which is EEI's whole business |
| Support | Someone who answers your users' questions, so you do not have to |
That last row is worth pausing on. Most authors of valuable code underestimate it, and it is often what turns a promising product into an unsustainable one.
What crosses the boundary¶
If you deliver interpreted code into a customer's environment, you have handed over the source. A license can govern whether something is allowed to run; it cannot stop someone reading what they already hold. Running as a Tool changes what is distributed:
| Shipping code into an environment | Your algorithm as a Tool | |
|---|---|---|
| What the consumer receives | The implementation | The results |
| Where it runs | Their infrastructure | The platform |
| What they can inspect | Everything you shipped | The interface, and the outputs |
| Improving it | A redistribution exercise | Deploy once; every consumer has it |
Be precise about that claim, because we would rather you trusted the precise version: this is a property of where code executes, not an assertion that code is unbreakable. Nothing about the platform makes an algorithm mathematically secret, and anyone who can invoke a function can study its behavior. What changes is that the implementation is never distributed to the environments that consume it — so protecting it stops depending on the access controls of every customer holding a copy.
Where consumers invoke it from¶
An API is only useful where the work happens, so the delivery surface matters as much as the capability:
| Surface | What it is for |
|---|---|
| The platform API and SDKs | Direct programmatic invocation, from an application or a pipeline |
| Seeq Add-on Calculation Webhook | A formula on an engineer's worksheet calls out; your algorithm runs; results come back as signals usable in formulas, conditions, and displays |
| A Seeq Add-on | Installed through Seeq's Add-on Manager — an Add-on Tool on the Analysis Tools Panel, or a Frontend Plugin in the display pane — for work that needs an interface rather than a formula |
| The VirtualForge Toolbox | Discovery and use from inside Seeq, for people who will never call an API |
| The command line | Scheduled and scripted invocation, which is how industrial operations actually run repeatable work |
Neither Seeq path is hypothetical. EEI built an integration between Seeq and AWS Lookout for Equipment — train and run predictive models on data organized in Seeq, with the output surfaced back as Seeq signals, conditions, and properties. Lookout for Equipment is primarily an API; without something in between, using it means writing custom software. That is the shape of every algorithm Tool: a capability that exists but is impractical to reach, made reachable from where the work already happens.
What language your code is in¶
Straight answer, because it is the first thing an engineer asks:
| Plugin SDK | Status |
|---|---|
| Python | Available — the SDK EEI's own tools are built against today |
| JVM | Planned |
| .NET | Planned |
If your implementation is Python, you are on the path that exists. If it is something else, the practical question is not "which SDK" but whether your algorithm can be invoked from a Tool — a compiled binary, an existing service, a model artifact behind a runtime. Often it can. That is a five-minute conversation and worth having early rather than assuming either answer.
What you bring¶
The honest list, because a partner who knows this up front moves considerably faster:
- A callable boundary. Inputs and outputs you can describe. If the method currently only works when you are in the room adjusting it, making it a function of stated inputs is the first real work — and it is work on your side of the line, not ours.
- Predictable execution. How long a call takes, what it needs in memory, and how it behaves on bad input. Long-running work is fine; it becomes a job rather than a request. It just has to be knowable.
- Declared dependencies. What your code needs in order to run, pinned to versions.
- Versioning discipline. Improving your algorithm is the point. Changing its behavior silently, under consumers who built decisions on the old behavior, is the thing that ends products.
- Test vectors. Known inputs with known-good outputs. This is what lets us validate a deployment without understanding your method — and it is the item authors most often do not have.
- Someone who answers questions about the method. Not the code: the domain. When a customer asks why the answer is what it is, that question has to reach a person who knows.
The commercial side¶
Why this is worth doing together rather than alone¶
The division is unusually clean, which is the main reason it works:
| What each side already has | |
|---|---|
| You | The method, the domain judgment, the data or experience behind it, and the credibility with the people who need it |
| EEI | An operated integration cloud, connectivity to the systems your algorithm needs data from, a presence inside Seeq, delivery and entitlement machinery, and thirty years at the seam where physical process meets digital analysis |
Neither half is a product. Your algorithm without a delivery platform stays a consulting engagement, delivered once, to one client, by the person who wrote it. A delivery platform without valuable algorithms is plumbing. Together it is something a customer can subscribe to.
There is a compounding effect on top of that, and it is the actual strategic reason EEI cares: capability on the platform combines. Your Tool becomes reachable from every connector we already have, and every connector we add later makes your Tool reachable from one more source system — without either of us doing anything. That is work neither party has to repeat.
Ways this can be structured¶
From lightest to most committed. All four are real; which fits depends on how much certainty you need and how much of the build you want to own:
| Shape | You bring | EEI brings |
|---|---|---|
| Design partner | A real algorithm and a real user, plus honest feedback on what does not work | Platform, SDK, and engineering time — and the third-party model gets shaped around your actual needs rather than our assumptions |
| Cost-shared co-development | A share of the build cost, and the domain truth | A share of the build cost, the integration cloud, and the operational maturity. This is the Let's Collaborate! model on our main site: split the cost and risk of a tailored build so neither side carries it alone |
| Tool subscription | The method, and its continued improvement | Hosting, entitlement, metering, billing, delivery surfaces, and support — your Tool becomes something a customer subscribes to, with revenue terms agreed between us |
| Engineering services | The requirement | A straight build, delivered and handed off. Still on the table, and sometimes the right answer |
Commercial terms — revenue treatment, licensing, exclusivity, certification requirements — are settled per arrangement, and we are not going to publish numbers on a page and pretend they apply to every case. Ask, and you will get specifics for your situation.
Ownership, plainly¶
Because this is the question that stalls conversations when it is left implicit:
- You keep your algorithm. Contributing a Tool is not an assignment of your intellectual property. It is a deployment and distribution arrangement.
- EEI keeps the platform. The SDK, the Category Manager framework, and the operational capability underneath are ours, and are what you are getting the benefit of.
- Jointly created work gets written down. Integration code, packaging, and a domain Category Manager built for your category are the parts where ownership genuinely needs stating rather than assuming, and they belong in the agreement.
- Confidentiality runs both ways, before anything technical is exchanged.
- Neither side assumes exclusivity. If exclusivity is what you want, it is a negotiated term, not a default.
What EEI wants out of it¶
Stated so you can weigh it, since a partner who cannot see the other side's incentive is right to be cautious.
Every capability added to the platform makes every other capability on it more valuable, so growing the Tool surface beyond what one small company can build is the strategy — not a favor. And the third-party path has to be proven by someone eventually. We would rather learn where it is wrong with partners who will tell us the truth than with a stranger after we have committed to a design.
Where this sits in EEI's priorities¶
Two things are true, and you should have both before investing time.
This is not what EEI is selling this quarter. Near-term focus is connectors and the solutions customers have already bought, because a small company with finite engineering capacity delivers sold work first. The third-party contribution path is direction, funded as capital and demand justify it.
Sold work moves the queue. That is not a caveat, it is how the plan is built: a capability someone has committed to buy is scheduled ahead of the next unsold platform milestone. So "this is not our near-term focus" and "a serious partner conversation can change the near-term focus" are both accurate — and the second one is why an early conversation is worth more than a later one.
Early conversations shape what gets built first. That is not a sales line; it is a description of how a company this size sets priorities.
A first conversation¶
Worth an hour, and useful even if nothing proceeds.
Bring: what the algorithm does and who needs it, what form it is in today, who consumes it now and how, and your own read on what stops it being a product.
You will get: an honest assessment of whether the platform earns its place in your case, a sketch of what your Tool would look like on it, and a specific answer about timing rather than a general one. If the answer is that you do not need us, we would rather say so in the first hour than the sixth month.
Start here: the Endeavor Engineering resources hub.
Related¶
- Plugin architecture — the mechanics: isolation, categories, packaging, and the contribution path, with an honest account of which parts exist today.
- Algorithms as Tools — the concept this page acts on, from both the author's and the consumer's side.
- Tools and the Toolbox — what a Tool is, the categories they fall into, and how one reaches a user.
- Connectors ++ — the operational capability set EEI's own connectors inherit, and the standard your Tool would be delivered to.
- VirtualForge — the platform underneath all of it, and where it actually stands.