The Redundancy Problem

The shelving system and indexes were working. But as Glagalbagal expanded his records to include more detail per entry — tracking not just the herd count but the manager's name, the terrain type, the grazing area, and the feed rate — the cave was filling up at an alarming speed. Blortz, who was responsible for the physical maintenance of the shelves, raised the issue.

The Bloat

Blortz: I have been examining the records on Shelf 2. Every single entry for Location 2 contains the same information: "Location 2, Manager Mvantika, Plains terrain, sixty land-units, quality three." This appears on every monthly record — all forty-eight of them. That is forty-eight copies of identical information.

Glagalbagal: The records need to be complete. If someone reads a record, they should be able to understand it without looking at anything else.

Blortz: At the cost of storing the same five facts forty-eight times. Across all four locations and three years of records, you have nearly two hundred copies of information that has changed exactly once — when you replaced Frojj with Threntik at Location 1 last year.

The numbers were stark. Roughly a third of the pebbles and baskets in the entire cave were devoted to storing location details that almost never changed. The monthly data that actually varied — the count, the growth, the feed consumption — occupied the remaining two-thirds. The cave was running out of shelf space, and most of what filled it was redundant.

The First Fix

Glagalbagal's instinct was to abbreviate. Instead of writing "Location 2, Manager Mvantika, Plains terrain, sixty land-units, quality three" on every record, he would write just "Location 2" and let the reader look up the rest.

But look up where? Currently, the details existed only within the monthly records themselves. If he removed them from the records, they would be gone.

The Location Tablet

Blortz proposed creating a separate tablet for each location — a single stone slab containing everything that was true about that location and rarely changed: its name, its manager, its terrain type, its area, its grazing quality.

Monthly records would then contain only the things that changed each month: the date, the herd count, the growth, and a reference to the location tablet — "see Location Tablet 2 for location details."

Glagalbagal carved four location tablets and placed them on a new shelf at the front of the cave. Then he went through every monthly record and removed the duplicated location information, replacing it with a small mark indicating which location tablet to consult. The cave lost roughly a third of its pebble arrangements overnight. Blortz was visibly relieved.

The Structured Format

While restructuring the records, Glagalbagal noticed another source of confusion. Different velociraptors had been recording monthly data in different orders. Some wrote the date first, then the count, then the growth. Others wrote the count first. One particularly creative velociraptor at the Thjervak Plains had been recording growth before the count, which made the records look like the herd was shrinking when it was actually growing — the growth number was being read as the count.

Glagalbagal imposed a fixed format. Every monthly record would contain fields in exactly the same order:

Field 1: Date. Field 2: Location reference (which location tablet to consult). Field 3: Herd count. Field 4: Growth since previous month. Field 5: Feed consumed.

The format was carved on a template tablet that hung above the recording station. Every velociraptor followed the same order. Any record could be read by any velociraptor without being told what each field meant — field 3 was always the count, regardless of who wrote it or when.

The Join

The system worked well for storage and retrieval. But it complicated certain queries. When Stravjek returned asking for a report on "each location's name, terrain type, and average growth over the past year," the answer required combining information from two different places — the location tablets (for name and terrain) and the monthly records (for growth).

A velociraptor had to: look at a monthly record, find the location reference in field 2, walk to the location tablet shelf, find the referenced tablet, read the name and terrain, walk back, read the growth from field 4, and combine everything into a single report. This back-and-forth between two shelves for every record was slow.

But the alternative — putting all the information back into every monthly record — would recreate the redundancy problem. Glagalbagal accepted the tradeoff: queries that combined information from multiple sources were slower, but the data was stored cleanly and without duplication.

The Temporal Problem

Several months later, Glagalbagal replaced Mvantika as manager of Location 2 with a triceratops named Ghredj (Mvantika had retired to pursue competitive moss-fermentation, a growing sport in the region). Glagalbagal updated Location Tablet 2: the manager field now read "Ghredj" instead of "Mvantika."

The problem surfaced when Thvajjik requested a historical report. He wanted to know which manager was responsible for Location 2 during a specific period last year — a period when Mvantika had still been in charge. Glagalbagal pulled the monthly records from that period, followed the location reference to Location Tablet 2, and read the manager's name: Ghredj.

But Ghredj had not been the manager during that period. Mvantika had. The location tablet showed the current state, not the historical state. By eliminating the redundant manager name from the monthly records, Glagalbagal had also eliminated the historical record of who had been managing at the time.

Blortz: When the manager's name was stored in every monthly record, each record captured who was managing that month. Now the records just point to the location tablet, which only knows the current manager.

Glagalbagal: So I should put the manager's name back in the monthly records?

Blortz: Only the things that change and whose history matters. The terrain type and area do not change — those can stay on the location tablet. But the manager's name changes, and the historical value matters for audits. That should be in the monthly record.

Glagalbagal revised the format. Field 2 remained the location reference (for terrain, area, and other stable facts). But he added a new Field 6: the manager's name at the time of the record. This meant a small amount of duplication — the current manager appeared both in the monthly record and on the location tablet. But the duplication was intentional and bounded: only fields whose history mattered were duplicated, not everything.

The general principle was not "never duplicate" but rather "duplicate only when the history of the duplicated information is more valuable than the cost of maintaining it." Like most principles Glagalbagal had discovered, it was less clean than he would have liked, and required judgment rather than a mechanical rule.