Skip to main content

Functions

EngineersAnalystsDomain experts
In one minute

A function is a computation that lives in the model: it consumes time series and events, produces new ones, and the derivation is recorded in the graph.

Today you can model functions, name a computation, wire what it reads and what it produces. Running them inside the platform is the roadmap part, and it is one of the two building blocks still being built.

On the roadmap

Function execution is on the roadmap. What exists now is the modelling side: a function is a kind of resource, it takes its place in the graph, and a derived series can record what it was derived from. The execution engine, running the computation on schedule or continuously over live data, is what is coming. This page covers both, clearly separated.

What a function is for​

Every operation already runs computations on its data: cleaning a noisy signal, converting units, aggregating to hourly figures, deriving a rate from two totals. Today those live in spreadsheets, scripts and report logic, outside the model, which has two costs:

  • Each consumer recomputes. The same cleaning logic exists four times, in four tools, drifting apart quietly.
  • Nothing remembers the derivation. A derived figure carries no record of what produced it, which is precisely the gap lineage is meant to close.

Registering the computation as a function in the model fixes both: one definition, referenced by everything downstream, with the derivation recorded where the data lives.

What this is worth to the business​

The value of functions is easy to understate because each instance looks small. It compounds across four lines:

One number per question. When the same KPI is computed in three tools, meetings start with twenty minutes of reconciling whose figure is right. A function makes the derivation singular: everyone consumes the same cleaned level, the same energy-per-tonne, the same availability figure. The tank story below ends with a reorder decision made on the corrected series, and the point is that everyone's reorder decision uses that same series.

Expertise becomes infrastructure. The engineer who knows that this tank breathes with the weather, or that spikiness in that bearing signal matters more than its level, currently applies that knowledge by hand, in a spreadsheet, until they leave. Written as a function, the trick runs forever and its author becomes visible in the model, the same key-person argument that motivates the whole platform, applied to calculations.

Answers while they still matter. A windowed computation is at worst minutes old; a nightly batch is at worst a day old. For anything with an expiry, an excursion, a dosing decision, a filling tank, that difference is the whole value of the answer.

New questions start higher up. Once cleaned series and features exist, the next question assembles from them instead of starting at raw samples. This is the compounding thesis again, applied to computation: the tenth derived signal is mostly built from the first nine.

What you can do today​

Model the computation as a function resource

Create it like any other resource, with a clear name and a Function classification. "Hourly energy aggregate, Line 3" is a resource somebody can find, point at and discuss, even before it executes anywhere.

Wire its inputs and outputs

Relate the function to the series and events it reads, and to the series it produces. A derived series can record what it was derived from, so the ancestry structure exists in the graph from day one.

Keep the computation itself versioned somewhere honest

Until execution ships, the logic still runs wherever it runs today. The gain is that the model now names it, so the spreadsheet stops being invisible.

A function is a node: it reads, and it writesThree signals and the maintenance history in; new typed events out, anchored to the equipment.21-VT-2101 · vibration21-TT-2102 · bearing temp21-ST-2103 · shaft speedMaintenance eventsreadsFunctionbearing stress detectorwritesEventsstress detectedconcernsPump P-101Wiring this, which series a function reads, what it writes, and which equipment its output concerns, works today.When execution ships, this exact wiring is what runs, and what lineage is read from.
The wiring drawn: three signals and the maintenance history feed a stress detector, whose output is not a dashboard number but new typed events, anchored to the pump they concern. Note what the graph makes queryable in both directions: everything this function depends on, and everything that depends on this function.

This is genuinely worth doing now: when execution arrives, the functions you have modelled are the ones that start running, and the lineage they have been promising becomes live without remodelling anything.

What the execution engine will add​

The planned capabilities, in the order most operations need them:

CapabilityWhat it doesTypical use
Data cleaningNoise, outliers, drift and gap-filling handled once, at the sourceOne cleaned series everyone consumes, instead of four private cleanings
TransformationUnit conversions, derived signals, calculated ratesEnergy per tonne computed once, consistently
Feature extractionTurning raw signals into inputs models can learn fromVibration statistics per shift, fed to a failure model
Streaming computation with windowingThe above running continuously over live data, in sliding or tumbling windowsA 15-minute rolling average that is always current, not recomputed nightly
And moreAggregation, resampling, event detection from continuous signalsTurning a threshold crossing into a typed event

Cleaning, drawn​

Cleaning a tank level that breathes with the weatherA chemical tank level computed from two pressure sensors climbs on warm afternoons.Nothing was added: the sensors feel the temperature, not the chemical.Air temperatureTank levelas measuredcorrectedwarm afternoon, phantom fillThe function subtracts the level swing the temperature correlation predicts, and nothing else.Raw stays raw; the corrected series is derived, flagged, and the one reports and reorder decisions consume.
A true story shape: the tank level climbed every warm afternoon, and the chemical never moved. Because temperature explains the swing, the function can subtract exactly that component and nothing else, so what remains, the slow decline, is consumption you can actually reorder against. Raw stays raw; the corrected series is derived and flagged.

Feature extraction, drawn​

Feature extraction: many numbers in, a few meaningful ones outThe raw signal is too dense to act on. The features are what people, models and agents actually use.Vibration, rawmillions of samples per shiftFunctionevery shiftRMS 4.2 mm/sthe energy of the vibrationPeak 9.8 mm/sthe worst single impactCrest factor 2.3spikiness, a bearing tellEach feature is a new series in its own right, smaller, comparable across machines, and carrying its derivation.
Nobody acts on a million vibration samples. They act on whether the energy is rising, how hard the worst impact was, and whether the signal is getting spiky, which is a bearing's tell. Extracting those into named series is what makes the raw data usable by people and learnable by models.

Windowing, drawn​

Tumbling windows: every event lands in exactly one sliceThree sensors streaming, time cut into equal windows.When a window closes, its aggregate is emitted seconds later.window 1window 2window 3window 421-PT-103421-PT-103521-TT-2001window sizetimeEvery event belongs to exactly one window, no overlaps, no gaps. One aggregate per sensor per window,emitted while the stream keeps flowing. Sliding windows overlap instead; the slicing idea is identical.
The stream has no natural end, so windows manufacture ends: equal slices of time, every event in exactly one of them, an aggregate emitted as each slice closes. This is what replaces the nightly batch, and why a 15-minute average is at worst 15 minutes old rather than a day.

Event detection, drawn​

From a continuous signal to typed eventsThe signal never says anything; it just varies.Detection functions decide when the variation means something.alarm thresholdEventsAlarmStressAnomalyNew conditionThe signal is continuous; what it means is discrete. Each detection lands as a typed event, anchored to theequipment it concerns, in the same event log as every alarm and work order, ready to overlay, query, or wake an agent.
Four different shapes, four different meanings: a spike past the threshold, a sustained elevation that never quite alarms, an oscillation that is abnormal for this signal, and a settle onto a new operating level. Only the first would be caught by a classic threshold; the other three are exactly what detection functions exist for. The types are yours to define, and each event lands anchored to its equipment, ready to wake an agent or an operator.

Two properties matter more than the list:

  • Lineage accrues automatically. A value produced through a platform function carries its ancestry without anyone documenting it, which is what makes the planned lineage capability complete rather than partial.
  • The learning step moves into the model. Agents and ML stop living in notebooks beside the platform and start consuming features the model itself produces.

Functions stack​

Read the four capability drawings in order, cleaning, features, windowing, detection, and they are one pipeline: cleaning produces trustworthy series, features condense them into meaning, windowing keeps both current, and detection turns them into events. Each layer consumes the one below, so every function you add raises the floor the next one starts from. That stacking, not any single computation, is what turns a data platform from a place data sits into a place understanding accumulates.

Branch it like code​

Because a function is a node with wired inputs and outputs, it can be cloned and modified, and the clone is a branch in the graph, the same move as branching in version control, git clone applied to a data flow. Reuse the whole pipeline, swap only the part you want to improve, and run both versions against the same live inputs.

Branching a pipeline, like branching codeClone the cleaning function, improve the algorithm in the copy, and race both against the same inputs.21-LT-4012 · tank level21-TT-4013 · air tempcloneClean · v1in productionClean · v2cloned, new algorithmlevel · corrected v1what reports use todaylevel · corrected v2the challengercompare accuracyagainst the lab dipsBoth branches read the same inputs and write parallel series, so the race is fair and cheap to judge.Promote the winner. The loser and the comparison stay in the graph, so the pipeline improves without losing its history.
The challenger is drawn outlined because that is its status: cloned, modified, and not yet trusted. Both versions read identical inputs and write parallel series, so judging them is a fair comparison against ground truth, here the manual lab dips, rather than an argument. Promote the winner; the race itself stays in the graph as history.

This is what makes improving a calculation safe. The alternative, editing the production algorithm in place, means last quarter's figures were computed one way and this quarter's another, with nothing recording the change. Branching keeps the production series untouched while the challenger proves itself, and when it wins, the promotion, the loser and the comparison all remain in the graph. It is the branching half of the git-for-data idea, made concrete: the wiring and the parallel series can be modelled today, and racing them automatically is what execution brings.

And then an agent picks it up​

Functions end where agents begin, and the division of labour between them is worth stating precisely, because it is an economic argument as much as an architectural one.

Functions do the mechanical 99%. They are deterministic, always-on and nearly free per evaluation: computing an average, checking a curve, comparing against a threshold costs effectively nothing, millions of times a day. Agents do the judgement 1%, and they are the opposite: powerful, open-ended, and expensive per invocation. Pointing an agent at raw samples wastes its reasoning on arithmetic; pointing it at nothing means paying it to watch a quiet plant.

The chain below is the resolution: the function is the tripwire, the agent is the responder. Detection runs continuously at function cost, and the expensive reasoning wakes only when something merits it. The same functions also give the agent its vocabulary, an agent handed crest factor rising, stress event at 14:32, level corrected for temperature starts its loop several steps ahead of one handed a million raw samples, and its conclusions are cheaper to verify because its inputs are named and flagged.

The subsea hydrate case makes the chain concrete.

From detection to action, every hop in the graphA function detects, the event wakes an agent, and the agent drafts. A person still approves.21-PT-3105 · pressure21-TT-3106 · line tempPigging eventsreadsFunctionhydrate risk watchwritesEventshydrate riskwakesAgentinhibitor planneractsdrafts dose + pigging runfor control-room approvalThe agent bypasses no one: it drafts, and the control room approves. And because every hop is a node or an event,the whole chain from raw signal to action is traceable afterwards, which is what makes autonomy auditable.
Every hop is graph machinery: the function's inputs are wired relationships, its output is an event, the event wakes the agent, and the agent's draft goes to the control room, not past it. Trace the chain backwards afterwards and you have the audit trail for why the inhibitor dose changed.

And the arrow eventually points back the other way. An agent that discovers a useful relationship, say, that a temperature explains a tank level's swing, can propose it as a function: reviewed by a person, then running permanently. That is the difference between an insight and an asset, a discovery that would once have been a slide in a presentation becomes a computation that never stops running, with its origin recorded.

Where functions sit in the bigger picture​

Functions are layer 2 of the three-layer model: the things your assets do, including the computations that turn their raw signals into meaning. A function that cleans a signal serves the same role in the model as a pump that moves fluid, it is a named thing with inputs, outputs and relationships. They are also the behaviour of a digital twin, and executing them is what moves a twin from level two to level three of the maturity ladder.

External references
Go deeper