Skip to content

Algorithms as Tools

Connecting data is the precondition. Doing valuable work on it is the point.

Most of what gets called integration stops at movement: this system's data becomes visible over there. That is necessary, and on its own it is plumbing. The intelligence in Connected Intelligence includes the work performed on connected data once it is reachable — and an algorithm, a formula, or a model can itself be a Tool on VirtualForge, sitting alongside the connectors and data platforms rather than being something separate you have to build around.

That has consequences for two different people: whoever owns a valuable algorithm, and whoever wants to use one.

Status: planned. The enabling architecture — the platform, Category Managers, and the Tool model — exists today, and a partner collaboration is active. What does not exist yet is a published library of algorithm Tools, and the packaging and naming are still being worked out. If this is relevant to you now, that is a conversation worth having early: early conversations shape what gets built first.

If you own an algorithm

You have something genuinely valuable and hard to reproduce — a method refined over years, a model trained on data nobody else has, a formula that encodes real domain judgment. Turning it into something other people can buy is a different problem from making it work, and it is usually the problem that stops it.

Make your work a product, not a project

Before anyone can use your algorithm, somebody has to build and operate the software around it:

  • Somewhere for it to run, that stays running.
  • Authentication, so the right people reach it and others do not.
  • Entitlement and metering, so access can be granted, limited, and billed.
  • Versioning, so improving it does not break the people depending on it.
  • Support, so a user's question reaches someone who can answer it.
  • A delivery surface, so it can be invoked from wherever the work actually happens.

None of that is your expertise, none of it differentiates you, and all of it has to exist. It is why so much valuable analytical work stays a consulting engagement — delivered once, to one client, by the person who wrote it — instead of becoming a product.

The platform supplies that layer. You keep doing the part only you can do. What that would involve in practice — the technical shape, what you would need to bring, and how a commercial arrangement between us could be structured — is in Bring Your Algorithm to the Forge.

Where your implementation lives

There is a second problem that authors of interpreted code know well. If your algorithm is written in something like Python and you deliver it into a customer's environment, you have handed over the source. Operation and inspection cannot be separated by a license: a license key can govern whether something is allowed to run, but it cannot stop someone reading what they already hold.

Delivering the algorithm as a Tool changes what crosses the boundary:

Shipping code into an environment The 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 gets it

To be precise about the claim, because precision matters here: 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 goodwill and access controls of every customer who holds a copy.

If you want to use one

From the consuming side this looks much simpler: advanced or proprietary analytics, invoked from where you already work, without a procurement project or a custom build.

In Seeq there are two delivery paths, and they answer different questions. One puts the capability inside a calculation; the other puts it inside the interface. Which one fits depends on how the work is invoked, not on what the algorithm does — and a single Tool can use both.

The calculation path: an Add-on Calculation Webhook

Seeq's Add-on Calculation Webhook extends Seeq's calculation capability with compute that lives somewhere else. Seeq makes an HTTPS request to a configured API endpoint, sending a payload from Workbench to the external server and bringing the response back. The results are then available in the Formula editor, usable in formulas, conditions, and displays alongside everything else in the analysis.

This is the path that matches the argument above, and not by coincidence: the algorithm runs on the platform, and only the result crosses into Seeq.

Why not the Add-on Calculation Engine? Seeq also offers an Add-on Calculation Engine, which runs Python scripts against Seeq signals — by key or by sliding window — with the results directly accessible as signals in Seeq Formula. It is a capable mechanism, and it is the wrong one for a proprietary method: the Python runs inside the customer's Seeq, which means the implementation has been delivered into their environment. That is precisely the trade the webhook avoids.

The interface path: a Seeq Add-on

The second path is a Seeq Add-on, installed through Seeq's Add-on Manager — the point-and-click interface where users request Add-ons and administrators install, configure, and update them. This is how the VirtualForge Toolbox reaches people inside Seeq, and how any Tool with a real user interface is delivered.

Seeq's add-on surface has two families, which is the distinction worth holding onto:

  • Add-on Calculations surface in Formula. The Webhook and the Engine above are both of this kind.
  • Add-on Manager elements surface in the Seeq interface and are distributed as a single .addon package, which can carry more than one element at a time. Four are supported: Add-on Tools, Frontend Plugins, Data Lab Functions, and Formula packages.

Of all of these, three carry most of the delivery in practice:

Mechanism How it reaches the user Where it fits
Add-on Calculation Webhook External compute, reachable from Seeq Formula An algorithm invoked as part of a calculation
Add-on Tool Functionality on the Analysis Tools Panel or the Home Screen, opened with a reference to the workbook and worksheet it was launched from A guided task that needs to know which analysis it is acting on
Frontend Plugin A user interface built with standard web technology, placed in the Analysis Display Pane, the Analysis Tool Panel, or the Home Screen Interaction with what is on screen, including Trend View

The two paths are complementary rather than competing. A Tool that needs both — an interface to set the work up, and a formula-reachable result afterward — is delivered as one Add-on carrying both, and appears in the Toolbox either way.

None of this is the same as a formula item

Worth separating, because these get confused and they do genuinely different things:

  • A formula item references signals that already exist. It reorganizes and expresses what is already there — this is how our metadata connector builds asset trees without copying data.
  • An Add-on Calculation invokes custom compute. Something runs that Seeq could not have calculated on its own, and the answer comes back.

The first is about structure. The second is about capability you did not previously have.

A precedent that already shipped

This pattern is not hypothetical. EEI built an integration between Seeq and AWS Lookout for Equipment: train and run predictive equipment models on data organized in Seeq, with the model 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.

Why we care about this

Because it is the same principle as everything else here, applied one layer up. We connect rather than duplicate so data can stay where it belongs while becoming useful elsewhere. Algorithm Tools let capability stay where it belongs — with the people who built it — while becoming useful to everyone else.

Democratizing useful algorithms is the goal: let an author expose their method to the world without building a software company around it, and let a customer consume it as a subscription rather than a project.