---
title: "The live state and the record: two memories of a company operating system"
url: "https://hurukan.com/blog/the-live-state-and-the-record-two-memories-of-a-company-operating-system"
description: "A company operating system needs two memories: the live state modules change every second, and the record of every event, proposal and decision for the audit."
---

# The live state and the record: two memories of a company operating system

October 21, 2026·5 min read·Editorial team

A quiet archive room seen from the side: an archivist at a standing desk with a single tablet showing an abstract blue-and-grey ledger, behind him long rows of identical grey storage boxes under a thin blue LED line, morning light from a high window

A credit controller opens the approval inbox. An agent has proposed releasing a held order: the customer paid two overdue invoices this morning, the open balance is now within the limit, the proposal cites both payments. She approves. Three months later the customer disputes a fee, and the auditor asks a simple question: what did the system know at 09:14 on that day, and who decided?

The modules can answer the first half only if nothing has been overwritten since. The payments table shows today’s balance, not that morning’s. The order shows its current status, not the one the agent saw. The proposal itself is gone from the inbox because it was acted on. A system in which agents propose and people approve produces decisions at a pace at which “we will reconstruct it” stops being an answer. It needs a second memory.

## Why the modules’ store cannot be the only memory

The store under the modules is built for one thing: to change the current state of the company safely. One order, one lock, one transaction, indexes tuned to find a single row fast. That is exactly what it should be, and nothing here suggests replacing it.

Superintelligence asks the same data different questions, and each of them strains that store.

**Reading at scale.** A proposal about one customer reads thousands of rows across orders, invoices, payments and complaints. A model scoring delivery risk for the whole order book reads millions. Reads of that size compete with the transactions the store exists to protect.

**History.** The store holds what is true now. Most of the questions an agent is asked are about change: what the limit was when the order was accepted, how long this supplier has been slipping, whether this customer’s margin has fallen for three quarters. A store that overwrites cannot answer them; a memory that keeps versions can.

**The whole company at once.** The order is in commerce, the complaint in customer service, the pallet in inventory, the stop in operations. In one operating system they share a data model, which is the point of the system. They still do not share a convenient place to read all of it at once without touching the tables the modules are writing to.

**What the agent saw.** A proposal is defensible only if the data it was made from can be shown later, exactly as it was. That requires a snapshot, not a current value.

Hurukan’s answer is two memories under one ontology: the **live state**, which the modules change second by second, and the **record**, an immutable, versioned history of every event, every proposal and every decision. The [Data layer](https://hurukan.com/system/data) that holds both is in build; what follows is how it is being designed.

## What the record is made of

The record is not a product. It is three decisions, each made once.

**File formats are the bricks.** Each event and each snapshot of a table is written to files in an open format. Rows that travel between modules and connectors go as [Apache Avro](https://avro.apache.org/docs/1.12.0/specification/), where the schema travels with the data and compatibility between writer and reader is a formal rule. Data that lies still and is read by the column goes as [Apache Parquet](https://parquet.apache.org/docs/file-format/), where a question about two columns across millions of rows touches two columns. Which format serves which job is the subject of [Parquet and Avro: the event between modules and the record superintelligence reads](https://hurukan.com/blog/parquet-and-avro-the-event-between-modules-and-the-record-superintelligence-reads).

**A table format is the plan.** Files alone are a heap. A table format — Delta Lake, Apache Iceberg, Apache Hudi, Apache Paimon — keeps the metadata that says which files make up a table at a given moment, what its schema is, and how it has changed. Because the files themselves are never edited, every version of the table remains readable: that is where time travel comes from, and with it the answer to “what did the agent see at 09:14”. The choice between them is a choice about the audit trail, and it is made in [The audit trail is a table: Delta Lake, Iceberg or Hudi](https://hurukan.com/blog/the-audit-trail-is-a-table-delta-lake-iceberg-or-hudi).

**A catalogue says where the truth is.** Something has to hold the pointer to the current version of each table and decide who may read it. That catalogue, not the files, is where sovereignty is won or lost. It runs on infrastructure the company chooses, and the [security and sovereignty layer](https://hurukan.com/system/security-and-sovereignty) treats it as part of the company’s own estate.

## How an event travels

A module changes the live state: a payment is posted. The same change is published as an event under a contract — a named schema with a version. A pipeline lands the event in the record as a new file under the table’s metadata, within the latency the business has asked for. Nightly is enough for a margin report. Minutes are needed for a credit decision. Seconds are needed for a work queue on a shop floor, and seconds cost more than minutes, which is why the tier is a decision rather than a default.

The record is written in one direction. Agents and superintelligence read it, together with the [ontology](https://hurukan.com/system/ontology) that tells them what a “held order” or a “slipping supplier” means. They do not write to it directly. An agent’s output is a proposal that lands in the approval inbox; a person approves; the module changes the live state; the change is published as an event; the event lands in the record. The decision log is itself a table in the record, with the proposal, its sources, the approver and the time.

## What the agent saw, and who decided

That loop is what makes the auditor’s question answerable. The record at 09:14 is a version of the tables, not a reconstruction. The proposal is a row with the identifiers of the rows it read. The approval is a row with a person’s name. Nothing in the chain depends on anybody remembering.

The same property serves the people building the system. When a new version of an agent is being evaluated, a day of events can be replayed from the record against it and its proposals compared with the ones people actually approved. The record is the evaluation set.

## Agents build the Data layer, under approval

Hurukan is built and extended by agents, and the Data layer is no exception. An agent drafts the pipeline that lands a new event type. An agent proposes the schema change when a module gains a field, and the compatibility check against the registry runs before anyone reads the proposal. An agent plans the compaction of small files and the expiry of old snapshots. Each of these is a proposal with a diff and a test result, and a person approves it. The approval is recorded like any other.

What stays with people is what cannot be undone or cannot be inferred: the contract between modules, the retention of history and the deletion of a person’s data, the choice of format and catalogue, and any upgrade of a table’s protocol that would lock out an older reader.

## The record you can take with you

Every piece of the record is in a format that other engines read. If the company leaves, it leaves with its history: the files, the table metadata and the catalogue, on its own infrastructure. Where the company already has tools that read one format — a Microsoft estate, a Snowflake subsidiary — the same files can be exposed in that format without a copy, which is the subject of [One record, readable by the tools you already have](https://hurukan.com/blog/one-record-readable-by-the-tools-you-already-have-xtable-and-uniform). And where domain agents need the live state rather than the history — the work queue, stock, the approval inbox — a table format built for streams keeps that state readable without polling the modules’ store, which is [the case for Paimon](https://hurukan.com/blog/the-state-domain-agents-read-paimon-for-the-work-queue-stock-and-approvals).

## A test you can run today

Take one decision your company made last quarter on the basis of a report: a credit limit, a reorder, a price. Try to produce the data exactly as it was on the day of the decision, and the name of the person who took it. Count the hours. That number is the cost of having one memory, and it is what the record is for.

-   record
-   lakehouse
-   audit
-   table formats
-   sovereignty

## Keep reading

-   [One identity for people and agents: who may do what](https://hurukan.com/blog/one-identity-for-people-and-agents)
-   [An agent that writes to the ERP: the line between read and write](https://hurukan.com/blog/an-agent-that-writes-to-the-erp)