The history sits in the system that collected it. AVEVA's own course in PI administration describes the ordinary shape: an interface reads the control system and sends the values into a PI Data Archive on its own server, and a client asks that archive for them (PI System Administration). Ignition writes tag history into a SQL database, or into a file inside Ignition itself (Ignition Tag Historian). WinCC keeps its tag logs on the WinCC machine, and a CSV is an export someone runs or a script (WinCC Unified Logging). IGSS, used in water, keeps an object historian on the IGSS server and exports a graph or a log to CSV from there (IGSS). A file on a second computer exists when someone has configured a report job, or when an operator takes the file out. It is not what those systems do on their own.
Norsk Vann wrote in 2026 that a municipality's operating data sits across the control system, the network register, the finance system and spreadsheets, and that reporting is often manual because the systems are poorly set up for a direct export (report 300/2026). Some Norwegian control systems keep the history in the supplier's cloud (one of them says so on its own page). So the first question on site is where the numbers are taken out today, and who is allowed to read the store they live in.
Who
Three people, and the third one waits. The person who already takes numbers out of the control system: an operator, or the integrator who built it. An engineer who knows the plant, for an afternoon, to answer the tags Auge refuses. IT and OT security when a live read is wanted, because that is a read-only account and, where the networks are separated, a firewall rule. A first week on a copy of files needs the first two.
Where it runs
One machine the plant already owns, on the network where that data is already allowed to be. A PC or a virtual machine beside the historian or the SCADA server, in the operations zone or the demilitarised zone. For the first weeks, a laptop with a copy of the files. On Windows it is one zip, unpacked into a folder, with its own Python: nothing is installed, and it needs no administrator rights. On Linux it is Python and numpy. The language model, if you turn it on, runs on the same machine. The program does not go on a PLC, a panel or a controller.
The same program runs in your own cloud account when that is where the files, or an MQTT broker, already are: one container on Azure, AWS, Google Cloud or your own Kubernetes, on a private network. A plant that wants part of the work in the cloud keeps the reader beside the data and runs the console in the account. A plant that wants the readings to stay on site uses the machine and skips the container. We do not host the data. What is locked down, and what we have not deployed.
While it runs, it does not use the internet. There is no licence server and no telemetry. A sign-in through Entra ID, or any other identity provider, needs a path to that provider on port 443, so a network without that path uses named accounts on the machine. Sign-in is off until you turn it on. What a security team can check, including the sealed run, is on its own page.
Three ways in
A file the plant already makes. CSV or Excel, in the plant's own language and clock, a few weeks of it, and an instrument index as a PDF if there is one. This is day one, and it opens no session to the control system. Someone takes the file out, or a report job the plant already runs writes it. We do not assume that job exists.
A read-only question to the store that already holds the history, when the picture should move without a person copying files. AVEVA PI through its Web API, each request a GET. A SQL historian in the shape Ignition uses. OPC UA, one outbound session to a server the plant already runs. Each writes hourly files into the same folder, and the rest of the product reads the folder. Each was tested against a server we ran ourselves. None of them has yet been tried against a customer's PI server, Ignition database or OPC UA server. A real PI server needs its certificate and a read-only account, which we have not set up. MQTT subscribes to a broker the plant, or its own cloud account, already runs, and writes the same files; it does not publish. That subscriber is tested against a broker we run in the tests, not yet against a customer's broker, and it does not read Sparkplug B. We write no driver for Modbus, S7 or EtherNet/IP. That layer stays with the plant's own gateway.
A copy that already leaves the control network, when one exists: a report on a schedule, a file share a job already writes, or a second historian in the demilitarised zone. If the history lives in a supplier's cloud, that is a different network, and it is named before anyone treats the site as sealed.
How current it is
As current as the last file in the folder, or as the last poll when a reader is on. The folder is checked every half minute. New readings on tags it already understands are added without working the plant out again. It is worked out in full when the tags change, when someone answers, and at least every hour. That is current enough for a shift, and for a sensor that died this morning. It is not in the control loop. The first pass needs weeks of history, which is why the store that already has those weeks is the useful source, and a file of this morning alone is a thin start. When the folder is worked out, the shift note is written into it as auge-shift.md: what moved, what went quiet, and which open work orders the data still backs. The previous note is kept beside it, and the new file lists the lines that were not in that one. A language model does not write it. A person may add a line under Notes. Nothing in the file is sent.
What we have not done
We have not yet read an export from a Norwegian waterworks. The exports we have measured come from utilities and plants that published their data in Denmark, the United Kingdom, Germany and Spain, and from a test rig. The pass marks and the failures are on the results page.