Enhancement Sub-Protocol · Category 1110
Binary
Pictography
& Codebooks
The Sumerian scribes of 3000 BCE used minimal clay tokens whose meaning expanded through shared context. BitPads Binary Pictography applies this principle to binary data.
Four bits per symbol. Sixteen semantic concepts per codebook. Richness held in shared context rather than transmitted with every message.
The Sumerian scribes of 3000 BCE used compact clay tokens whose meaning expanded through shared context between sender and receiver. The mark was minimal. The codebook was in the reader's knowledge. BitPads Binary Pictography is this same principle implemented in nibble streams: four bits per symbol, sixteen semantic concepts per codebook, semantic compression that is 14× more compact than the most compact text alternative for the same payload.
One nibble. Selects one of 16 entries in the active codebook.
Per codebook. 65,536 codebooks referenceable in extended form.
4 bits vs 56 bits minimum (7 ASCII chars) for the same semantic concept.
4 status reports in 2 bytes vs 51 bytes of text. Spacecraft telemetry example.
Binary Pictography is available in three contexts:
- Note blocks — Note encoding type = 10 (Stream category reference)
- Telegraph Emulation streams — Category 1110 with active codebook
- Any stream — with an active codebook and the binary pictography channel declared in the Stream-Open Control byte
Core Mechanism
Nibble Streams — Four Bits Per Symbol
A nibble is 4 bits. A nibble stream is a sequence of 4-bit symbols. Two nibbles per byte. Each nibble selects one of 16 entries in the active codebook. The codebook maps the 4-bit index to a full semantic concept.
Symbol 1
Symbol 2
2 symbols per byte
10-byte Note block → 20 semantic events
50-byte session over constrained link → 100 status reports
Each report is a complete semantic concept from the shared codebook. Zero overhead per report beyond the nibble itself.
At 2 symbols per byte, a constrained 50-byte session carries 100 status reports — each a complete semantic concept from the shared codebook. The only transmission cost is the nibble itself. No labels. No delimiters. No schema headers. The receiver holds the codebook; the stream carries only indices.
System Design
The Codebook Architecture
A codebook is a 16-entry mapping from 4-bit index to semantic concept. The codebook exists as a pre-shared lookup table — agreed at session setup, referenced by index in the stream, never transmitted as content.
| Property | Specification |
|---|---|
| Entries per codebook | 16 (indexed by 4 bits: 0000–1111) |
| Active codebook count | 1 per stream at any given time (can shift mid-stream) |
| Total codebook space (basic) | 32 codebooks (5-bit index in rolling shift byte) |
| Total codebook space (extended) | 65,536 codebooks (16-bit index in extended declaration) |
| Transmission cost per concept | 4 bits (one nibble) |
| Equivalent text label ("NOMINAL") | 56 bits minimum (7 ASCII bytes) |
| Compression ratio vs text | 14× at minimum. Higher for longer labels. |
| Pre-sharing mechanism | Session Layer 1 custom extension block or firmware-resident table |
Codebook Structure
| Index (4 bits) | Binary | Entry (example) |
|---|---|---|
| 0 | 0000 | Concept 0 — Session-agreed semantic at index 0 |
| 1 | 0001 | Concept 1 |
| 2 | 0010 | Concept 2 |
| 3 | 0011 | Concept 3 |
| 4 | 0100 | Concept 4 |
| 5 | 0101 | Concept 5 |
| 6 | 0110 | Concept 6 |
| 7 | 0111 | Concept 7 |
| 8 | 1000 | Concept 8 |
| 9 | 1001 | Concept 9 |
| 10 | 1010 | Concept 10 |
| 11 | 1011 | Concept 11 |
| 12 | 1100 | Concept 12 |
| 13 | 1101 | Concept 13 |
| 14 | 1110 | Concept 14 |
| 15 | 1111 | Concept 15 |
Codebook 0001 — Example
Universal Codebook — 16 Standard Entries
Codebook 0000 (index 0) is the Universal codebook: globally agreed, no session declaration needed. The following shows Codebook 0001 — the spacecraft status codebook used throughout the BitPads specification examples.
| Index | Binary | Codebook 0001 — Spacecraft Status |
|---|---|---|
| 0 | 0000 | Nominal |
| 1 | 0001 | Warning |
| 2 | 0010 | Critical |
| 3 | 0011 | Burn complete |
| 4 | 0100 | Fuel low |
| 5 | 0101 | Power nominal |
| 6 | 0110 | Comms nominal |
| 7 | 0111 | Attitude nominal |
| 8 | 1000 | Thermal nominal |
| 9 | 1001 | Data rate normal |
| 10 | 1010 | Orbit nominal |
| 11 | 1011 | Navigation lock |
| 12 | 1100 | Downlink active |
| 13 | 1101 | Uplink active |
| 14 | 1110 | Fault detected |
| 15 | 1111 | Emergency |
Four Status Reports in Two Bytes
The canonical BitPads Binary Pictography example: spacecraft attitude control system reporting four subsystem states simultaneously using codebook 0001.
Interactive Nibble Visualisation
Index 3
Index 5
Index 6
Index 0
Enter a binary nibble stream (e.g. 0011 0101 0110 0000) or hex bytes (e.g. 35 60). Select codebook and decode. For reverse: enter meanings (one per line) and encode.
Session Configuration
Session-Declared Codebooks
At session open, via the Custom Domain Extension Block or Layer 1 codebook declaration, the sender declares a custom codebook for the session. The codebook maps 4-bit indices to session-specific concepts. The receiver holds the codebook in a firmware-resident lookup table. The nibble stream references entries. No labels transmitted. Pure semantic compression.
Nominal, Warning, Critical, Burn complete, Fuel low, Power nominal, Comms nominal, Attitude nominal, Thermal nominal, Data rate normal, Orbit nominal, Navigation lock, Downlink active, Uplink active, Fault detected, Emergency.
Idle, Starting, Running, Paused, Stopping, Error, Maintenance, Calibrating, Overload, Temperature high, Vibration high, Power fault, Conveyor stop, Feed empty, Output full, Emergency stop.
Received, Pending, Cleared, Rejected, Reversed, Partial, Settled, Disputed, Escrow, Released, Expired, Converted, Allocated, Consolidated, Obligated, Audited.
Stable, Improving, Degrading, Alert, Critical, Medication due, Vitals normal, Heart rate high, SPO2 low, BP elevated, Temperature elevated, Movement detected, Alarm cleared, Call staff, Emergency, Device fault.
The session codebook declaration is a one-time overhead: the 16-entry codebook is transmitted once at session open and then held by the receiver. Every subsequent nibble in the session references the codebook by index. For a 1000-event session, the one-time overhead is 16 codebook entries × 8 bits per entry = 128 bits, amortised across 1000 events at 4 bits each = 4000 bits of payload. The codebook overhead is 3.2% of the payload.
Dynamic Mechanism
Rolling Codebook — The Shift Mechanism
Enhancement field 110 bytes (flags=110: Priority+ACK, no Continuation) within an active enhancement stream update the active codebook. The lower 5 bits of the C0 code identity carry the new codebook index.
When the receiver encounters a byte with flags=110 at a signal slot position:
- Lower 5 bits = new codebook index (0–31 in the basic form)
- Active codebook shifts immediately at that byte position
- All subsequent nibble symbols decoded against the new codebook
- Both sender and receiver derive the shift sequence from the session key
- An interceptor without session context cannot determine which codebook is active
The shift mechanism allows a single stream to carry content from multiple semantic domains without any in-band framing overhead beyond the single shift byte. A stream can switch from spacecraft system states to fuel telemetry to orbital parameters and back, with each domain reading from its own codebook, at the cost of one byte per domain transition.
Signal Slot Mechanism
SO/SI Signals — Mid-Note Codebook Shifts
In Note blocks with encoding type=10 (binary pictography), mid-Note codebook shifts use the SO (Shift Out, 0x0E) and SI (Shift In, 0x0F) C0 signals in the P7 signal slot (Post-Task/Pre-Note position).
Security Model
Semantic Obscuration — What It Is and Isn't
The rolling codebook creates semantic obscuration — a specific and intentional property that is distinct from cryptographic security. Understanding the distinction is essential for correct deployment.
- An interceptor without session context cannot determine which codebook is active at any point in the stream
- They see bytes, but cannot decode nibbles to their semantic meanings
- With N codebooks and a session-key-derived shift sequence, the interceptor faces an N-choice ambiguity at each shift point
- The semantic layer is opaque to passive observation without the session key
- Meaningful resistance to casual interception on low-threat channels
- Appropriate for sensor networks and industrial telemetry
- Appropriate for semi-public broadcast channels where semantic privacy vs passive observation is needed
- Cryptographic guarantee — the byte values themselves are transmitted in cleartext
- Physical layer protection — layer inspection reveals the bytes
- Resistance to determined adversaries with knowledge of the agreed codebooks and the session key derivation
- A substitute for transport-layer encryption
- Suitable as the sole protection mechanism for high-threat channels
- Forward secrecy — if the session key is compromised, past streams can be decoded
Deployment note: Semantic obscuration is appropriate when the threat model is passive casual interception — a receiver that can see the wire but does not hold the session codebook mapping. It is not appropriate as a substitute for encryption in adversarial threat models. The mechanism was designed for sensor networks, industrial controllers, and semi-public broadcast where the primary goal is preventing casual semantic decoding, not resisting active cryptographic attack.
Protocol Element
Codebook Declaration Grammar
The Stream-Open Control byte's Codebook field (bits 5–6) declares the codebook mode for the stream. This interacts directly with the rolling codebook mechanism.
| Code | Mode | Rolling Allowed | Effect |
|---|---|---|---|
00 ▾ |
Universal | Yes (if Update Flag = 1) | Start on universal codebook. May shift to any session codebook via rolling mechanism. |
The stream begins with the globally-agreed universal codebook active. No session negotiation needed. Both sender and receiver derive meaning identically from nibble index 0–15. If the Update Flag (bit 8 of Stream-Open Control byte) is 1, rolling codebook shifts via flags=110 bytes are permitted during the stream. | |||
01 ▾ |
Session-declared | Yes (if Update Flag = 1) | Start on the codebook declared at session open. Rolling shifts permitted if Update Flag set. |
The stream begins with the session-declared codebook active. The codebook was declared in the Layer 1 custom extension block at session open. The receiver already holds this codebook from session negotiation. Rolling shifts from this baseline are permitted if the Update Flag is 1. | |||
10 ▾ |
Cipher shift | Always | Active codebook = session baseline + cipher offset. Start offset derived from session key. Baseline not directly observable from the stream. |
The strongest obscuration mode. The active codebook index is not directly observable from the byte stream — even if an interceptor can see the shift bytes (flags=110 + code index), they cannot determine the actual active codebook without knowing the session baseline. The baseline itself is session-derived via the session key. Rolling shifts apply a further XOR offset from the observable shift index. This means: even knowing the shift bytes, an interceptor cannot determine which codebook is active at any point unless they hold the session key. | |||
11 ▾ |
Extended | Depends on extended declaration | Extended codebook declaration follows in the bytes immediately after the Stream-Open Control byte. Allows arbitrary codebook definition at stream open — 16-bit codebook index space. |
When Extended mode is declared, the next 2+ bytes after the Stream-Open Control byte carry the extended codebook declaration: a 16-bit codebook index (0–65535) identifying the specific codebook from the receiver's extended codebook library. This allows up to 65,536 distinct codebooks to be referenced within a session. The extended declaration bytes are not stream content — they are consumed by the parser before the stream body begins. | |||
Worked Example
Encoding Example — 4 Status Reports in 2 Bytes
Detailed walkthrough of the canonical Binary Pictography example from the BitPads specification. Scenario: spacecraft attitude control system reporting four subsystem states simultaneously.
Worked Example
Decoding Example — Receiver Side
Same 2 bytes. Receiver side. Full decoding from wire bytes to semantic events.
Record Component
Binary Pictography in Note Blocks
Binary Pictography is declared as a Note encoding type (type=10, Stream category reference). The Note Header declares the encoding; the Note content is a nibble stream decoded through the active codebook.
Type
Variant
(escape=1111)
When encoding type = 10, the Note content is a nibble stream decoded through the active codebook. The Note Header's variant field (bits 3–4) selects a variant of the active codebook — providing four sub-variants per codebook without requiring a full codebook shift.
SO/SI mid-Note shifts (Section 7) operate via the P7 signal slot. This allows a single Note block to contain content encoded against multiple codebooks — with seamless transitions driven by the P7 signal slot's SO/SI C0 control signals. The transition does not break the Note block; the content continues in the same Note after the shift.
Note block pictography at scale: A 10-byte Note block in binary pictography mode carries 20 semantic events. A session with 100 Note blocks carries 2,000 events in 1,000 bytes of Note content (plus Note headers). The same session in text would require approximately 14,000 bytes of label content minimum. The structured BitPads record overhead (identity, timestamp, CRC) is shared across all events in each record — it does not multiply.
Integration
Telegraph Emulation + Pictography Together
The combination of Category 1110 (Telegraph Emulation stream) with binary pictography active creates the most semantically dense binary communication channel in the BitPads protocol family.
Every byte = enhanced C0 byte (flags + code identity)
Active codebook provides semantic context for C0 code interpretations
Rolling codebook shifts update semantic context mid-stream
Legacy receivers see standard C0 controls throughout
BitPads receivers decode typed events with full semantic resolution
This is the Sumerian principle in binary: minimal marks, shared context, rich meaning.
In this mode, the C0 code identity within each stream byte serves as a compressed semantic pointer into the active codebook, while the P/A/C flags carry the event's priority, confirmation, and continuation state. A single byte carries: a 3-bit flag state AND a 5-bit semantic index into the codebook. The codebook entry carries the full semantic concept.
Design Lineage
Design Heritage Connections
Every mechanism in the Binary Pictography system has a lineage reaching back to the history of communication. The connections are not metaphorical — they are structural isomorphisms.
Compact marks whose meaning expanded through shared context between sender and receiver. The scribe pressed a minimal token into clay. The reader interpreted it through a shared codebook held in cultural knowledge. The token itself was compact — the richness was in the shared context, not in the mark.
Connection: BitPads nibble codebook — 4-bit index, semantic meaning held in the shared codebook, zero label overhead per event. The same structural principle separated by 5,000 years.
Baudot's five-bit code used two shift states — "Letters" and "Figures" — to double the vocabulary from 32 to 64 symbols without adding bits. A single control signal (Shift Out / Shift In) changed the interpretation of all subsequent symbols. The shift state was maintained by the receiver.
Connection: BitPads SO/SI codebook switching — the same structural mechanism: a single control signal changes the semantic interpretation of all subsequent content. One SO byte shifts the active codebook. One SI byte restores it. Zero content bits consumed by the shift itself.
Samuel Morse assigned the shortest codes to the most frequent letters (E = dot, T = dash) and longer sequences to rare letters. The code was optimised by frequency — common signals carried the minimum weight. The priority flag operates on the same principle: the most important signals receive elevated handling regardless of their code identity.
Connection: BitPads Priority flag (P bit) — signals marked with P=1 receive pre-emptive handling. The most urgent events carry the flag. Legacy equivalence: BEL was always the highest-priority C0 control. Priority BEL (0x87) is the direct structural successor to the telegraph operator's emergency key.
The telegraph key closed or opened a circuit — one binary bit. The complete meaning of a signal was in the timing and sequence of key contacts, read through a shared protocol (Morse, Baudot, etc.). The contact itself carried no label. The receiver decoded through trained knowledge.
Connection: Every byte in a Category 1110 stream is a complete signal event. The C0 code identity plays the role of the key contact sequence; the codebook plays the role of the trained operator's knowledge. The mechanism is direct: binary contact → shared codebook → complete semantic event.
The unbroken line: Sumerian clay token (4000+ BCE) → Baudot shift state (1870) → SO/SI in ASCII (1963) → BitPads codebook shift (2024). The structural principle — minimal mark, shared context, rich meaning — has been rediscovered and implemented in every major binary communication standard. BitPads Binary Pictography is its most compact binary-native expression: four bits per semantic event, sixteen events per codebook, 65,536 codebooks per session.