The perimeter

From the machine
to the decision.

This page answers a practical question: where we operate and what we take responsibility for. Five levels, from the hardware in the datacentre to the line of code that was missing. Between us and the client, there is no one else.

// the chain of responsibility

Five levels.
A single point of accountability.

Most industrial projects do not fail on technology: they fail at the handover points between different suppliers. When the entire chain is in the same hands, those points do not exist.

100% Swiss
01
Infrastructure
Datacentre and cloud

The physical place where data lives. Ours, in Switzerland.

02
The data
From machines to systems

Making machines of any age talk, without touching them.

03
The model
A single operational truth

Correlating what today lives in separate systems.

04
Intelligence
Reading the context

Anticipating rather than reacting, on data that actually exists.

05
The software
Adapt or build

Bending what exists to fit the process. Building only the rest.

A single contract A single point of accountability No intermediaries in between
// 01 — infrastructure

The client's data
is sacrosanct.

The data entrusted to us remains the client's: it is not monetised, not resold, not delegated. Held in Switzerland, in a datacentre we own, because this responsibility cannot be transferred to anyone.

This is not a marketing argument: it is an architectural consequence. Owning and managing the infrastructure directly allows us to answer precisely where the data is located, who accesses it and under which jurisdiction it falls.

For a manufacturing company this matters more than it might appear: production data reveals how much is being produced, at what margins, for which clients. This is information that one rarely wants to entrust to infrastructure one does not control.

One of our commitments

The data entrusted to us remains the client's. Held in Switzerland, because this responsibility cannot be transferred to anyone.

  • Owned datacentreThe building, servers, storage, networking and security systems are managed directly by us, in Switzerland. We do not entrust the storage of operational data to hyperscalers or external sub-suppliers.
  • Private cloudVMs, databases, message broker, application server, encryption, DNS. Sized for the SME, not for the enterprise client.
  • nFADP and GDPRProcessing compliant with Swiss data protection law and, for European clients, applicable GDPR requirements. Any external services or data transfers are declared and agreed in advance.
  • ContinuityDisaster recovery, backups, 24/7 monitoring. The same level given to large clients, at the scale of the SME.
// sustainability

The most sustainable datacentre
is the one that wastes no cooling.

About half the energy in a traditional datacentre does not serve computing: it serves cooling. Acting there is the choice that truly makes a difference — more than any downstream offset.

Industry 5.0

Lake water cooling

Cooling makes use of deep lake water, naturally cold throughout the year. The energy required for climate control drops significantly compared to a traditional compression system — and the heat is not dispersed into the city air.

100% renewable energy

All power comes from renewable sources, with no residual share from fossil fuels. This is a contractual condition of the infrastructure, not an annual average compensated after the fact.

Residual emissions offset

What remains after reducing consumption is offset through reforestation projects in South America, with verifiable certification. First reduce, then offset — never the other way around.

Why we mention this

Not for environmental positioning: because it becomes your data. Manufacturing companies face growing reporting obligations throughout the supply chain, and the footprint of the digital services they use falls within that scope. On request, we provide consumption data and certifications for your reporting.

// 02 — the data

Every machine has a language.
We speak it natively.

The main technical challenge in integrating a real factory is the variety of protocols: OPC-UA, Modbus, Ethernet/IP, Profibus, MQTT, proprietary protocols from individual manufacturers, legacy SQL databases, CSV files generated by software from the 2000s.

No machine is left out. Most platforms require plants already set up for Industry 4.0. We have no such prerequisite: whether the facility is new or the result of decades of layered investment, every machine can become a data source.

Without touching anything
Read-only
No modifications to the PLC, no agents to install on servers, no reprogramming. The original data is never altered and the existing infrastructure remains intact.
What we connect
Practically everything
Machine tools and CNCs, robots, presses, packaging lines, process plants. And also diesel vehicles, forklifts and AGVs, energy meters, environmental sensors.
If the protocol is missing
We write it
The adapter library expands with every project. The module developed for one client becomes a standard, documented and maintained, available to all who can benefit from it.
How long it takes
Hours, not weeks
From connection to the first readable data. Each adapter is independent and is added progressively, with no impact on the rest of the system.
// 03 — the model

Acquire.
Normalise.
Correlate.

Collecting data serves no purpose if it remains in different formats that nobody puts in relation. The real work is building the context: making comparable quantities that originate from systems that do not communicate.

The discipline behind this

The PLC knows the machine has stopped. The ERP knows the order is behind schedule. The purchasing department knows the materials arrived late. Rarely does a system know that those three things are connected, that they happened within two hours of each other and that together they generated a three-day delay in delivery.

The result is not another report. It is the ability to answer, in real time, questions that previously required hours of manual work or simply had no answer.

The tool

The platform with which we implement this model is called arteMES. It is not an off-the-shelf product: it is the software infrastructure that allows the method to work, configured on the real process of each company.

The document we leave after a first meeting
arteMES — technical datasheet
Operational domains, connectivity, use cases · 9 pages
The questions we keep answering
  • Real cost of an orderWhat it actually cost, including downtime, energy, delays and rework.
  • The full cost of a stoppageNot the minutes of machine downtime: the propagation across the entire downstream chain.
  • Energy per processWhich machine, which shift, which order consumes the most — and what changes if planned differently.
  • Bottlenecks between departmentsWhere delay accumulates between production, quality and dispatch.
  • Operational prioritiesWhich order needs to be handled now to avoid tomorrow's problem.
// 04 — artificial intelligence

AI is not there
to collect more data.
It is there to read what you already have.

Artificial intelligence is not a module added at the end of a project. It is what becomes possible when the data model exists — and remains impossible until it does, however sophisticated the language model placed on top.

The question we ask before any discussion about AI is always the same: on which data? An AI trained on fragmented information produces fluent but wrong answers — which is the worst way to be wrong, because nobody notices.

Anticipate instead of react
Anomalies
before the stoppage
When data from multiple domains is correlated, deviations become recognisable before they become faults. This is not prophecy: it is a recurring pattern that nobody had ever seen in full.
Reading documents
Text
into operational data
Quotes, machine specs, tender specifications, technical documentation. Extracting from unstructured text the information needed to decide, without manual re-entry.
Query in natural language
Questions,
not queries
People with operational responsibility must be able to ask "which order is eroding margin" without knowing where the data lives or how to write a query.
Matching complex requirements
Projects
and funding
Our funding eligibility analysis tool works like this: models read the actual requirements from grants in our database, code calculates the amounts. How it works
// how we use it

The model does not invent numbers.
The code calculates them.

This is the rule we apply in every system we build, and it is what separates a tool on which decisions can be made from a demo that impresses in a meeting room.

Principle 01
Grounded in facts
The model works on real company data, not on what it has memorised elsewhere. If a piece of information is not in the facts, it is not cited.
Principle 02
Separated roles
The model reasons, interprets and correlates. Amounts, thresholds and calculations are produced by deterministic, verifiable and repeatable code.
Principle 03
Always verifiable
Every answer must be traceable back to the data from which it originates. When an element is estimated rather than confirmed, the system declares it.

Where it runs. Processing involving the client's operational data takes place on our infrastructure in Switzerland. When a project requires external models, we say so explicitly and define together which information may leave and which may not. The client's data remains the client's — even when talking about AI.

// 05 — the software

Not everything needs to be built.
Much needs to be adapted.

Building from scratch what already exists is the most expensive way to arrive late. When there is a product on the market that solves the problem, you install it and shape it to the company's real process — rather than shaping the process to the product.

Accelerating change

This is the most uncomfortable position for a supplier to hold, and the most useful for the client. An integrator that lives on licences has an interest in getting you to buy their product. A pure developer has an interest in building everything from scratch, because that is what they do. We earn nothing from either choice: we earn from the fact that the system works.

For SME management systems we appreciate Dolibarr — it is modular, open source, and adapts well to the scale at which we work. But it is not a constraint: if the right product for you is something else, or if the right one is what you already have, that is the answer and it changes nothing for us.

One of our commitments

Between us and the client there is no one else. We do not resell anything for margin, we do not accept agreements that steer our recommendations. The only interest we defend is the client's.

Why this truly matters: when nobody earns from the answer, the technical recommendation becomes a technical recommendation again.

The three paths · in this order
  • 01 · Reuse What the company already has is the starting point, not an obstacle to remove. Every system in use represents a real investment and competencies built over time: reuse is the default, replacement must be justified.
  • 02 · Adapt When a capability the company lacks is needed, the first step is to evaluate what exists on the market. The product is installed, configured and customised to the real process — we do not rewrite what someone else already maintains well.
  • 03 · Build Only for what truly does not exist: the missing protocol adapter, the integration with the management system that has no API, the business logic that no standard product covers.

The order is not negotiable. You move to the next level only when the previous one has been honestly ruled out.

What we see in the field

In industrial digitalisation projects, a significant portion of the overall effort is absorbed by systems integration — not by their function. This cost is almost always invisible in initial budgets and is rarely attributed correctly. That is precisely the work we take on.

A single point of contact

Tell us where
the data stops.

From infrastructure to decision. And if the missing piece does not exist, we build it.