Historian software is a database that stores time-series data from equipment and control systems at high resolution, with a trusted timestamp, and the values it writes are never edited afterward. That immutable record is the asset. The trend line drawn on top of it is only one view of the record, and views are cheap to make. The record matters more because a trend answers a question you already thought to ask, while the record is the only thing that can answer the question nobody has asked yet, two years from now, at 03:12. I got pulled into an investigation on a Tuesday. A batch had gone out of spec and the room wanted to know why. The historian did its job: eleven tags, one-second data, a clean trend showing the jacket temperature drifting for nineteen minutes before anyone touched it. Everyone nodded at the screen. Then the quality lead asked the only question that mattered. Has this happened before, and what did we do about it? The historian had no answer, because nobody had ever asked it to hold that. The person who knew had retired in March. What a process historian is actually good at It is timestamped, so it can settle an argument about sequence. It is high resolution, so it catches things a five-minute report smooths away. And it is written once, so it cannot be edited later to match whatever story the room needs today. A spreadsheet is whatever its author last saved. A historian is whatever the clock recorded at the time. When maintenance and production remember the same night differently, the historian is the only account in the building that was not written afterward by someone with a stake in the answer. That is a real asset and most operations underuse it. They open it during an incident and ignore it the rest of the year. What questions historian software cannot answer on its own The historian holds what the equipment did. It holds nothing about what people did. It does not know that the operator throttled back because the upstream tank was running low, or that a supplier lot changed the week before, or that a temporary bypass was put in on the night shift and taken out four days later. A hospital’s building management historian has the same hole: it logs the chiller tripping at 04:20 and knows nothing about the facilities call that rerouted the load. It does not know a maintenance job was closed in another system, a recipe was edited in another system again, or that someone made a judgement call at 02:40 that saved the run. It cannot tell you whether this is the first time or the fourth. The record holds states, not reasons. Time-series data captures the equipment exactly and captures the work not at all. That distinction is worth saying plainly. A record is what happened. History is what happened stored next to what was done about it. Most operations have a great record and almost no history, and then wonder why their AI project produces confident, generic answers. A model reading only tag values will tell you the textbook cause of a temperature drift. Your plant solved that drift its own way in 2019, and the reason is not in the tags. What compression and clock drift do to the record Two problems nobody raises, both fixable, both landing on IT. Compression deletes real data while the trend still looks right. Most historians only write a value when it moves by more than a set amount (the deadband) and throw away the readings in between. That is the right default, otherwise the disk fills. But the trend still looks correct after compression, which is exactly what makes it dangerous. The two-second excursion that explains the whole batch was inside the deadband, so it was never written. If nobody has looked at those settings since commissioning, they were set by an integrator on a Friday to make a storage number work. Clock drift puts events in the wrong order and the result still looks trustworthy. The historian runs on UTC. The ERP is local time. The lab instrument runs on a workstation clock nobody has checked in three years. Reconstruct an event across those three and you get an order of events that looks tidy and is wrong. Sequence is the whole reason you kept the data. There is a third one people rarely check. Some historians allow backfill and edits. Find out who can, and whether that action is logged somewhere those same people cannot reach. If a value can be changed without anyone seeing it, the record is no longer trustworthy, which was the only reason to keep it. Five questions to ask about your historian this week None of these need a project. They need an hour and someone with admin rights. Resolution after compression. For the ten tags an investigation would actually need, what is stored, at what interval, and for how long before it rolls up? Ask per tag, not per server. What the deadband discards. Pull one of those tags raw for one shift, next to the compressed version, and look at what is missing. Then decide whether you would accept losing that in an audit. One clock. What time source is every system synced to, and what is the measured drift right now? Write the answer down somewhere other than a person’s memory. The write path. Who can backfill or edit history, and where is that logged? What sits beside the values. Is there any place a person can write down what they did, tied to the same timestamp, and does anyone actually do it? For most operations the honest answer is no, and that is the gap worth closing first. Then run the real test. Pick a stoppage from about six months ago and try to reconstruct it from start to finish using only systems. Time it. Note every point where you had to walk over and ask a person. That list is the history your operation does not have yet. How to make the record answer “has this happened before” The historian was never supposed to be the whole answer, and holding it to that standard is unfair. A record becomes an answer when the work order, the batch record, the supplier lot, the reason code and the decision someone made sit beside the same equipment and the same timestamp, so that “has this happened before, and what did we do” is one question instead of six phone calls. Your historian will keep writing whether or not anyone maintains it. That is both its value and its risk. The record gets longer every year, and the number of people who can explain what is in it gets smaller every year, because the ones who can tell you what that nineteen-minute drift actually meant are retiring on a schedule nobody put in the plan. You already own the record. What it is worth depends on what you start storing beside it.