The Bad Update

GlagalCloud was running smoothly. Locks prevented race conditions. Deadlock prevention kept velociraptors moving. The system was serving fifteen customers, processing three hundred records per day, and generating more revenue than Glagalbagal's livestock operation and Hjelvran's trading business combined. Then Glagalbagal improved the addition tablet.

The Improvement

The original addition tablet — the one Glagalbagal had carved back in Part 7 — performed binary addition using the carrying procedure. It was correct, reliable, and slow. Each addition required a velociraptor to process each basket position sequentially, checking for carries one at a time. For large numbers, the process took several minutes.

Glagalbagal devised a faster method. Instead of checking for carries one position at a time, the new tablet pre-computed which positions would generate carries and handled them in batches. The velociraptor could skip ahead over positions that did not need carries, processing only the ones that did. For most numbers, this cut addition time in half.

He was pleased with the optimisation. He carved the new tablet, mounted it in place of the old one, and went to bed.

The next morning, Blortz was standing at the cave entrance with an expression that Glagalbagal had learned to associate with significant problems.

The Breakage

Blortz: The new addition tablet does not handle the case where a carry propagates through more than four consecutive positions.

Glagalbagal: That is very rare.

Blortz: Thvajjik's regional tax aggregate triggered it this morning. The carry propagated through six positions. The new tablet's batch method skipped positions five and six. The result was wrong by one hundred and twenty-eight.

Glagalbagal: One hundred and twenty-eight is—

Blortz: Two to the seventh power. The exact amount you would expect from two missed carry positions. The error was systematic, not random. Every calculation with a long carry chain is now wrong.

Glagalbagal reached for the old addition tablet — the one that had worked correctly for years. It was not on the shelf. He had removed it when mounting the new one. He checked the storage area. The old tablet had been placed in the discard pile.

Glagalbagal: Where is the discard pile?

Blortz: You told Grontch to clear the discard pile yesterday. The old tablets have been broken up for shelf material.

The old addition tablet — the correct one — no longer existed. The new addition tablet was wrong. Every calculation that used it for the past twelve hours was potentially incorrect. Reconstructing the old tablet from memory was possible but would take a day, during which all addition-dependent operations would be halted.

The Version Shelf

After the crisis was resolved (Glagalbagal re-carved the old tablet from memory, verified it against known results, and spent two days re-running every calculation from the affected twelve hours), he addressed the deeper problem: the old tablet should never have been destroyed.

He established the version shelf — a dedicated section of the cave where every instruction tablet, past and present, was preserved. When a tablet was updated, the old version was not discarded. It was moved to the version shelf with a label: the tablet name, the version number, and the date of replacement.

Addition Tablet v1: original, installed Part 7. Addition Tablet v2: batch-carry optimisation, installed yesterday. Known bug: fails on carry chains longer than four. Replaced by v3. Addition Tablet v3: batch-carry with unlimited chain length, installed today.

The version shelf grew. Each instruction tablet accumulated a history. At any point, Glagalbagal could walk to the version shelf, find a previous version, and reinstall it. Rolling back from a broken v3 to a working v1 took minutes instead of a day.

The Branch

The version shelf solved the problem of undoing changes. But it did not solve the problem of testing changes safely before deploying them.

The batch-carry bug would have been caught if Glagalbagal had tested the new tablet against a variety of inputs before replacing the old one. But testing on the live system was risky — if the test revealed a bug, real customer data might already be corrupted. He needed a way to test in isolation.

Blortz proposed what he called a branch — a separate workspace where changes could be tried without affecting the live system. The branch was a copy of the relevant instruction tablets and a small set of test data. A velociraptor would test the new tablet in the branch, running it against known inputs and comparing the outputs to expected results. Only after all tests passed would the new tablet be promoted to the live system.

Blortz: You carve the new tablet. You test it in the branch with sample data. If it works, you replace the live tablet. If it does not, the live system is untouched.

Glagalbagal: And the branch?

Blortz: Discarded. It served its purpose. The branch is temporary — a safe space for experimentation, not a permanent copy.

The Changelog

The final addition was the changelog — a stone tablet mounted next to the version shelf that recorded every change to every instruction tablet: what was changed, why it was changed, when, and by whom. The changelog served two purposes. First, it allowed anyone to understand the history of a tablet — why version 3 existed, what problem it solved, and what problem it introduced. Second, it provided accountability — if a change broke the system, the changelog identified who made the change and what their reasoning was.

Glagalbagal: The changelog says I changed the addition tablet to improve performance.

Blortz: And the next line says you broke regional tax calculations for twelve hours.

Glagalbagal: Must we record that?

Blortz: The changelog is not a celebration of your successes. It is a record of what happened. Including the parts you would rather forget.

The changelog was honest, complete, and occasionally embarrassing. It was also invaluable. When a customer reported an anomaly in a three-month-old calculation, the changelog could identify whether any instruction tablet had changed during that period and what effect the change might have had. Without it, diagnosing historical errors would require reconstructing every event from memory — an unreliable and slow process.

The End of the Beginning

Glagalbagal stood at the entrance to the cave — a cave that had started as a disorganised mess of pebble arrangements and was now a structured, secure, concurrent, versioned information system serving fifteen customers via pterodactyl protocol with binary encoding, Boolean logic, encrypted communication, digital signatures, and a priority-based job scheduler staffed by permanent and temporary velociraptors.

He had not planned any of this. Each piece had emerged from a specific problem: pebbles rolling away led to baskets; baskets overflowing led to place value; place value led to binary; binary led to Boolean logic; the need for delegation led to instruction tablets; instruction tablets led to loops and recursion; growth led to file systems and databases; distance led to protocols; demand led to cloud computing; threats led to encryption; parallelism led to locks and deadlocks; and mistakes led to version control.

Every invention was a response to a failure. Every failure was a consequence of the previous invention's limitations. The system was not designed from the top down. It was grown from the bottom up, one problem at a time.

Blortz: You know, a young woman named Trviksha came by yesterday. She works in the regional trade bureau. She asked whether GlagalCloud could answer questions that do not have clear rules — questions where the answer must be inferred from patterns in the data rather than computed from a formula.

Glagalbagal: That sounds like a different kind of problem entirely.

Blortz: It does. She seemed very determined.

Glagalbagal: She can have a shelf.