The Monthly Report

The check sum system was working. Corrupted records were now detected before anyone acted on them. But the pterodactyl delivery system had a different problem — one that the check sums made worse, not better.

The Weight Problem

Each record was now longer than ever. A single monthly report from one location contained thirty-odd baskets of data, plus a header declaring the field types (Part 24), plus a check sum and parity baskets (Part 26). For four locations sending monthly reports, each carrying full records for multiple animal types and status categories, the volume was substantial.

The pterodactyls were not happy. Grvetch, the most experienced carrier, could manage two stone trays per flight — roughly sixty baskets of data. A complete monthly report from a single location now required three trays. Four locations meant twelve tray-flights per month just for routine reports, not counting urgent messages, insurance documents, or the records Hjelvran and Grothvik needed transported.

Pterodactyl capacity was limited. Each flight took half a day. In bad weather, flights were grounded entirely. The system was approaching a bottleneck where the information processing was fast but the information delivery was slow.

Grvetch (translated from pterodactyl, which was mostly screeching and emphatic wing gestures): Heavy. Too heavy. My legs hurt.

The Observation

Blortz, examining the monthly reports side by side, noticed something.

Blortz: Location 2's report this month is almost identical to last month's. The herd count changed by three. The animal types are the same. The health status is the same. The feed level changed by four. Everything else — location code, manager, terrain type, grazing area — is identical. You sent thirty baskets to communicate two small changes.

Glagalbagal looked at the two reports. Blortz was right. Across the entire record, only five baskets had different values between this month and last month. The other twenty-five were unchanged. He was sending twenty-five baskets of information the receiver already had.

Glagalbagal: If the receiver already has last month's record, I only need to send what changed.

Blortz: Precisely.

The Delta

Glagalbagal called this a delta — a record that contained not the full current state but only the differences from the previous state. Instead of sending "the herd count is one hundred and sixty-six," the delta said "the herd count increased by three since last month."

A delta record was structured simply: a list of field positions that had changed, and their new values. If only positions 14 and 27-30 had changed, the delta contained five entries instead of thirty baskets.

The savings were dramatic. Most months, most fields at most locations did not change. The typical delta record was five to eight baskets — a single tray-flight for all four locations combined, instead of twelve. Grvetch's legs were visibly relieved.

The Reconstruction Problem

The delta system required that the receiver already had the previous month's full record. Without it, the delta was meaningless — "increased by three" meant nothing if you did not know the starting number.

This created a dependency chain. The current state could only be reconstructed by applying every delta in sequence from the last full record. If January's full record showed a count of one hundred and fifty, and February's delta said +5, and March's delta said -2, and April's delta said +8, then April's count was 150 + 5 - 2 + 8 = 161. But if March's delta was lost (a pterodactyl crashed, say), then April's count could not be determined.

Blortz: If any delta in the chain is missing, everything after it is uncertain.

Glagalbagal: Then we need to send a full record periodically — not every month, but often enough that a lost delta does not corrupt the entire history.

He settled on a quarterly cycle. Every three months, each location sent a full record — the complete state. In between, monthly reports were deltas. If a delta was lost, the receiver could request a re-send, and the damage was limited to at most two months of uncertainty. The quarterly full record served as a checkpoint — a known-good state from which deltas could be applied.

The Message Format

The delta system introduced a new problem: the receiver needed to know what kind of record had arrived before trying to read it. Was this a full record? A delta? An urgent alert? A response to a previous query? Different types of messages required different handling.

Previously, all messages were full records, so the question did not arise. Now, with multiple message types in circulation, a velociraptor receiving a tray from a pterodactyl needed to identify what it was before processing it.

Glagalbagal standardised the message format. Every message, regardless of content, would follow the same structure:

Section 1: The header tablet. A small stone slab at the front of the tray containing: - Sender code (which location or customer). - Date code. - Message type code (full record, delta, alert, query, response). - Sequence number (the ordinal number of this message from this sender). - Total tray count (how many trays make up this message, if more than one). - Check sum for the entire message.

Section 2: The body. The actual data — a full record, a delta, an alert description, or whatever the message type indicated.

Section 3: The check tablet. A separate slab at the back of the tray containing the check sum and parity information from Part 26.

The format was rigid. Every message began with the same header structure. A velociraptor could read the header of any message, from any sender, about any topic, and immediately know: who sent it, when, what type of message it was, and how to verify its integrity. The body was then read according to the rules for that message type.

The Protocol

Glagalbagal carved the entire format specification onto a large tablet mounted at the recording station. He called it the Message Protocol — a set of rules that governed how any message should be constructed by the sender and interpreted by the receiver.

Blortz: You have standardised the envelope. The contents may vary, but the envelope is always the same shape.

Glagalbagal: Any velociraptor at any location can read any message without being told what to expect. The header tells them.

Blortz: And any pterodactyl can carry any message without knowing what it contains. The protocol is independent of the content.

This was the same principle as Part 25 — the separation of mechanism from meaning. The protocol governed the structure. The content governed the meaning. Neither needed to know about the other.

The protocol tablet also specified what to do when things went wrong. If the check sum failed: discard the message, send a re-transmission request to the sender, and log the failure. If the sequence number was out of order: hold the message and wait for the missing one, or request a re-send. If the tray count said three trays but only two arrived: wait for the third, and if it did not arrive within two days, request a re-send of the entire message.

These rules were mechanical. A velociraptor could follow them without understanding the content of the message. The protocol handled the logistics of communication; the content was someone else's problem.