The Abstraction

Glagalbagal had built his system to manage a livestock business. Baskets and pebbles counted animals. Binary encoding distinguished sheep from cattle. Headers declared field types. Instruction tablets governed procedures. The entire apparatus existed to answer questions about herds.

Then the trader arrived.

The Trader

Hjelvran was a trader who operated between three river towns, moving grain, dried fish, and pottery. He had heard about Glagalbagal's system from Thvajjik the tax collector, who had mentioned — with his usual bovine neutrality — that Glagalbagal could produce any historical record in under a minute.

Hjelvran: I need to track my goods. I have sixty-three types of goods across three warehouses. I need to know what is in each warehouse, how much arrived this month, how much was sold, and to whom. Currently I keep this in my head, which was adequate when I had twelve types of goods and one warehouse.

Glagalbagal: My system tracks animals at grazing locations. It does not track goods at warehouses.

Hjelvran: What is the difference?

Glagalbagal opened his mouth to explain, then paused. What was the difference? A location code identified a grazing site. But "grazing site" was just a label — the code 0010 meant "Location 2" only because the lookup tablet said so. If the lookup tablet instead said 0010 meant "River Town Warehouse," the code would work identically. The baskets did not know or care what they represented.

Similarly, the animal type code 001 meant "sheep" — but it could equally mean "grain" or "pottery" or "dried fish." The baskets encoding the type were physically identical regardless of what the type referred to. The meaning was in the lookup tablet, not in the pebbles.

Glagalbagal: I... do not think there is a difference.

The Reconfiguration

Glagalbagal did not rebuild his system for Hjelvran. He duplicated it. He set up a separate shelf in the cave with new lookup tablets:

Location codes (for Hjelvran): 0001 = River Town North warehouse. 0010 = River Town South warehouse. 0011 = River Town East warehouse.

Item type codes: 000001 = Wheat grain. 000010 = Barley grain. 000011 = Dried river fish. 000100 = Smoked mountain fish. ...

The record format was identical to the livestock records: header, then fields for location, date, item type, quantity, and status. The instruction tablets for addition, subtraction, comparison, and reporting worked without any modification. An instruction tablet that said "read the field of type 011 (quantity) and add it to another quantity" worked the same whether the quantity was sheep or sacks of grain.

The procedures did not need to know what the data represented. They only needed to know its type — quantity, category, date, identifier — and how to operate on that type. The meaning — sheep or grain, pasture or warehouse — was irrelevant to the procedure.

The Healer

A month later, a healer named Grothvik arrived. She tracked patients — their symptoms, treatments, and outcomes. She had been keeping notes on bark scrolls, which were disorganised and illegible even to her.

Grothvik: I need to know which treatments work. If I give fever-bark tea to patients with joint pain, do they improve? I have two hundred patients and cannot remember them all.

Glagalbagal set up another shelf. Patient identifier codes. Symptom codes. Treatment codes. Outcome codes (improved, unchanged, worsened, deceased — this last code Grothvik insisted on including despite Glagalbagal's suggestion that it was morbid). The same record structure, the same instruction tablets, the same indexing system.

Grothvik's records were, structurally, identical to livestock records and trade records. The same addition tablet could sum the number of patients who received a given treatment. The same comparison tablet could compare outcomes across treatment groups. The same indexing system could answer "which patients with joint pain received fever-bark tea and improved?"

Grothvik: Your system was built for sheep.

Glagalbagal: It was built for pebbles. The sheep were incidental.

The Architect

The chieftain's architect, a stegosaurus named Plomkva whose tail spikes had been decoratively carved (a fashion statement that Glagalbagal found baffling), wanted to track construction projects. Materials, quantities, suppliers, delivery dates, site assignments. Glagalbagal set up a fourth shelf. Same structure. Same procedures.

Each new customer required only two things: a set of lookup tablets defining what the codes meant in their domain, and a shelf to hold their records. The machinery — the binary encoding, the headers, the instruction tablets, the indexes, the rule tablets — was shared across all of them.

The Relational Problem

Grothvik's data, however, introduced a complexity that livestock records had not. A patient could receive multiple treatments. A treatment could be given to multiple patients. The relationship between patients and treatments was not one-to-one — it was many-to-many.

In the livestock system, each record described one group of animals at one location. The relationship was simple: this group, at this location, on this date. But Grothvik needed to say: "Patient 0047 received Treatment 003 on date 1011 and Treatment 007 on date 1100." A single patient record could not hold an arbitrary number of treatments, because the record format was fixed — the header declared a specific number of fields.

Glagalbagal solved this the same way he had solved the cross-category problem in Part 17. He created two types of records:

Patient records: patient identifier, age, location, general health status. Treatment records: patient identifier, treatment code, date, outcome.

A patient with three treatments had one patient record and three treatment records. The treatment records referenced the patient record by identifier code — the same pointer mechanism he had used for reference tablets on the secondary shelves.

To answer "which treatments did Patient 0047 receive?" a velociraptor would look up all treatment records whose patient identifier field matched 0047. To answer "which patients received Treatment 003?" it would look up all treatment records whose treatment code field matched 003. Both queries used the existing indexing system.

Blortz: You have built the same structure three times now. Location tablets referenced by monthly records. Patient records referenced by treatment records. Goods records referenced by transaction records. It is always the same shape: one record describes a thing, another record describes something that happened to the thing, and the second record points to the first.

Glagalbagal: It is always the same shape because the world is always the same shape. Things exist. Events happen to things. You record the things and the events separately, and you link them.

The Realisation

Glagalbagal sat in the cave one evening after the last velociraptor had left. The shelves around him held livestock records, trade records, medical records, and construction records. The baskets were identical. The pebbles were identical. The instruction tablets were identical. The only differences were the lookup tablets — the thin layer of meaning that said "this code means sheep" or "this code means fever-bark tea."

The system he had built was not a livestock management system. It was not a trade system or a medical system or a construction system. It was a system for storing, retrieving, and manipulating structured information of any kind. The pebbles did not know what they represented, and they did not need to. The operations — add, compare, index, join, filter — worked regardless of meaning.

He had built, without intending to, a general-purpose information system.

The thought was both satisfying and slightly unsettling. A tool that can represent anything is powerful, but it is also indifferent. The same system that tracked a healer's patients could track a tax collector's audits or a chieftain's military deployments. The pebbles did not care. Whether that indifference was a feature or a problem was, Glagalbagal suspected, a question that would outlast him.