Connected asset platform
Telemetry from mixed hardware normalised into one event model, with live position, utilisation and exception alerting above it.
Algorix / Innovation System
We build the systems that other systems depend on.
An engineering company working across machine intelligence, telematics and enterprise automation.
SYS / ALGORIX-COREACTIVE
01Machine intelligence
02Telematics & IoT
03Enterprise automation
Position
Technology earns its place when it fits how an organisation already works.
Algorix works across machine intelligence, connected systems, automation, data and the platforms that carry them. The engineering starts from an operational problem that already exists — a decision made by intuition, a signal that never reaches the person who can act on it, a record trapped in a vendor's portal — and ends with a system somebody can run without us.
The problem space
What makes enterprise technology hard is rarely the technology.
These are the conditions the work usually starts in. They are observations about the field, not claims about any particular organisation.
- 01
Fragmented systems
Critical information lives across platforms that were each correct in isolation and were never designed to answer a question together.
- 02
Manual coordination
People spend their day moving information between systems — work that is orchestration, not judgement, and that software should be carrying.
- 03
Operational blind spots
The data exists. What is missing is the context that turns it into something a manager can act on before the shift ends.
- 04
Legacy that cannot be replaced
New capability has to integrate with systems that still run the business. Replacing everything is a proposal, not a plan.
- 05
Scale changes the problem
An architecture that answers in milliseconds at ten million rows and in minutes at ten billion has not scaled. It has expired.
- 06
Ownership of the record
History that only the supplier can read is a commercial position dressed as an architecture. It should survive a change of vendor.
Capabilities
What Algorix can actually deliver.
- S—01
Applied AI
A model built for one decision your organisation already makes, evaluated against that decision alone.
- S—02
Telematics Platforms
Fleet and asset visibility that survives a change of hardware vendor.
- S—03
Enterprise Automation
Closing the gap between a signal arriving and someone acting on it.
- S—04
Custom Platforms
Product engineering for organisations whose requirements do not fit a licence.
- S—05
Edge Deployment
Inference on hardware you already own, for data that cannot go to a third party.
- S—06
Technology Consulting
An engineering opinion, including the one where you should not build anything.
Technology
Capability domains, and what connects them.
D—01
Machine Intelligence
Models that make a decision an operator would otherwise make by hand, with the evidence attached.
D—02
Telematics & IoT
Reading physical assets continuously, and normalising what they say into one event model.
D—03
Enterprise Automation
Removing the manual step between a signal arriving and someone acting on it.
D—04
Data Systems
Time-series and geospatial infrastructure that stays queryable as it grows.
D—05
Digital Platforms
The operator-facing product: the part that decides whether any of the rest gets used.
D—06
Edge Computing
Processing where the data is produced, because some of it must never leave.
Representative architecture
The layers most of this work moves between.
A reference model, not a diagram of a deployed Algorix system. It is here because it is the vocabulary the rest of this site uses.
- L6
Experience
The operator's view. Bilingual, accessible, and the part that decides whether any of the rest gets used.
- L5
Applications
Workflows, worklists and exception handling — where a signal becomes somebody's task.
- L4
Intelligence
Models that produce a decision with its confidence and its evidence attached, so it can be interrogated.
- L3
Data
Time-series and geospatial storage that stays queryable as volume compounds. Every layer above depends on this one.
- L2
Integration
A normalisation layer above multiple vendors and eras, so one event model survives a hardware change.
- L1
Infrastructure
Where it runs, how it is deployed, and whether data residency is answered by architecture or by promise.
Engineering method
Six stages, and the discipline is in the first two.
How the work runs. The order matters more than any individual step: most failed systems were architected after the build had already started.
- 01
Understand
Establish the operational decision the system exists to serve, and what a correct answer looks like before anything is built.
- 02
Architect
Draw the boundaries and the interfaces. Decide what must be built, what can be bought, and what must never be coupled.
- 03
Engineer
Build the core capability, smallest first, with the evaluation in place from the beginning rather than bolted on at the end.
- 04
Integrate
Connect to the systems that already run the operation. This is where most of the real difficulty is, and where estimates fail.
- 05
Validate
Test behaviour, performance and failure. A system is not finished when it works; it is finished when its failure modes are known.
- 06
Operate
Observe it in production and keep it changeable. Hand over documentation and access so the client is not dependent on us.
Solution patterns
Shapes this work commonly takes.
Representative patterns, not delivered projects. They describe how the capability areas combine; the portfolio below lists what has actually been built.
Intelligent operations
A model attached to one recurring operational decision, surfacing a ranked worklist rather than a dashboard nobody opens.
Workflow orchestration
The route from a signal arriving to the person who can act, with the exception path and the audit trail treated as first-class.
Operations portal
One bilingual interface across distributed systems, with a permissions model that survives contact with a real organisation.
Portfolio
Selected work
One product built and evidenced, and a set of worked studies showing how a class of problem is approached. Each card says which it is.
P—01
GPSNexa
Vehicle tracking, built on Teltonika hardware.
GPSNexa is an Algorix product for GPS vehicle tracking, built around Teltonika telematics hardware. Algorix maintains the Teltonika device toolchain used to configure and deploy these units.
Teltonika FM-seriesTeltonika Configurator
Representative studies
Have a system worth building properly?
Tell us the operational problem rather than the technology you think you need. If the honest answer is to buy something existing, that is the answer you will get.