BP BitPads Protocol

BitLedger Universal Domain v1.0 · Engineering Applications

The Same
Algebra

Financial accounting and physical conservation are not analogous. They are identical. The wire format does not change. The mathematics does not change. Only the labels change.

Kirchhoff's current law states that the sum of all currents entering a node equals the sum of all currents leaving it. Double-entry accounting states that the sum of all debits equals the sum of all credits. These are not analogous laws — they are the same conservation invariant written in different notation. The algebra is identical. An engineer applying BitLedger to propellant tracking is using the same encoder, the same CRC-15 verification, the same cross-layer validation, and the same batch conservation check as a bank settling interbank transfers. The mathematical substrate is shared.

The Universal Domain specification formalises this identity. Layer 1 bits 3–4 carry a 2-bit domain code. When those bits read 01, the receiver switches from financial account pairs to 16 universal flow archetypes — but the 40-bit record structure is byte-for-byte identical. The value encoding formula N = A × 2^S + r does not change. The CRC-15 polynomial does not change. The cross-layer validation rules (bit 29 = bit 37, bit 30 = bit 38) do not change. What changes is the semantic interpretation of the 4-bit archetype field and the 6-bit quantity type code. Everything else is domain-agnostic by construction. An engineer who has written a BitLedger encoder for propellant mass accounting has simultaneously written an encoder that will work, without modification, for watt-hours, kilograms of steel coil, litres of water, or any other conserved scalar — because all of them obey the same invariant the encoder already enforces.

Domain bits
Layer 1 bits 3–4 = 01 → Engineering
Record size
40 bits / 5 bytes — identical to financial
Archetypes
16 universal flow types replace 14 account pairs
Quantity type
6-bit code replaces currency index (64 codes)
Conservation
Sum of signed flows = 0, enforced at wire level

Wire Format

Domain Encoding

The receiver learns the session domain in the first four bits it processes. Bit 1 is always 1 (SOH — session open). Bits 2–4 carry the wire format version and domain. By the time four bits have been read, the decoder knows which semantic layer to load. No preamble. No schema negotiation.

Bits 2–4 Domain Account field interpretation Quantity field Note
0 00 Financial Account pair codes — 14 financial pairs Currency index (USD, EUR…) Default. Backward compatible.
0 01 Engineering Flow archetypes — 16 universal types Quantity type code (mass, energy…) This document.
0 10 Hybrid Both matrices active per record Context-dependent per record Financial + physical in one session.
0 11 Custom Declared in extension block after Layer 1 Declared in extension block Receiver waits for extension before batches.

The bit display below shows a complete Layer 1 session header with domain bits 3–4 set to 01 (Engineering domain). The session is opened by a node with a 32-bit Sender ID; all subsequent records in this session are interpreted using flow archetypes and quantity type codes, not currency pairs.

Layer 1 Session Header — Engineering Domain (bits 3–4 = 01) — first 8 bits shown
1 1 SOH
2 0 Ver
5 1 Observe
6 1 Actuate
7 0 Override
8 0 Proxy
Mode / Permission Domain Declaration Version Flag Bits 3–4 = 01 → Engineering domain active for entire session

Switching the domain from Financial (00) to Engineering (01) changes exactly two things in the decoder: the label set for the 4-bit pair field (14 financial account pairs → 16 universal archetypes), and the label set for the 6-bit quantity type field (currency index → physical unit category). The 40-bit record structure, the value encoding formula, the CRC-15, and the conservation invariant check are all identical. An implementer who has built a financial BitLedger encoder changes two lookup tables to deploy in engineering mode. Every other component — value encoder, batch close handler, cross-layer validator, CRC computer — is reused without modification.

The 16 universal flow archetypes cover the complete vocabulary of directional flow semantics in any man-made system: Source-to-Sink (0000), Parent-to-Child (0001), Debtor-to-Creditor (0010), Mutual Exchange (0011), Loss/Dissipation (0100), Generation/Input (0101), Reservation/Escrow (0110), Repayment/Return (0111), Transformation (1000), Distribution (1001), Aggregation (1010), Internal Transfer (1011), Obligation Transfer (1100), State Commit (1101), Correction/Void (1110), Compound Continuation (1111). Every flow in the worked examples below maps to one of these 16 codes.

Deployment Scenario 1

Spacecraft Propellant Management

01
Aerospace · Propulsion Subsystem
Orion-Class Service Module — Bi-Propellant Tracking
5 bytes / burn record
JSON: ~450 bytes / burn

System context. An Orion-class service module carries a bi-propellant system: Monomethylhydrazine (MMH) fuel and Nitrogen Tetroxide (NTO) oxidiser, two tanks each propellant, feeding 16 attitude control thrusters plus one orbital manoeuvre engine (OME). Each burn event records propellant leaving a specific tank and arriving at a specific thruster manifold. The burn is logged the moment it occurs — not post-processed from a telemetry stream.

Domain bits (L1 3–4)
01 Engineering
Loads flow archetype table
Flow archetype
0000 Source-to-Sink
Tank → thruster manifold
Quantity type (L2 bits 36–41)
001 Mass · grams
SF=×1000, D=0 → kg precision
Precision step
1 gram
D=0, natural unit = g
Node identity (Sender ID)
32-bit space
8-bit subsystem · 8-bit tank · 16-bit thruster
Session scope
Mission phase
Ascent / transit / orbital insertion

Encoding a 450 g attitude control burn. MMH tank 1 fires thruster 7 for 450 ms, consuming 450 g of propellant. The encoding uses Quantity Type 1 (mass, grams), Scaling Factor ×1 (raw grams), Decimal Position 0 (integer gram precision).

Target value: N = 450 (grams, integer)
Shift select: S = 8 → A = floor(450 / 256) = 1
Remainder: r = 450 mod 256 = 194
Verify: (1 × 256) + 194 = 450 ✓ exact
For a 450 kg burn: N=450,000, S=8, A=floor(450,000/256)=1,757, r=88 → verify: 1,757×256+88=450,000 ✓
────────────────────────────────────────────────────────
BITLEDGER FLOW RECORD — PROPELLANT BURN
Session: Artemis IV / Propulsion Sub (node 03)
Batch: Phase 02 / Event 007 / Unit: grams (mass)
────────────────────────────────────────────────────────
Layer 1 bits 3–4 0 1 → Engineering domain active
RECORD BITS 1–40 (5 bytes = 40 bits)
────────────────────────────────────────────────────────
Bits 1–17 (A) 0 0000 0000 0000 0001 A=1
Bits 18–25 (r) 1100 0010 r=194 (0xC2)
Bit 26 (exact) 0 exact — no rounding
Bit 27 (rnd dir) 0 must be 0 when bit 26=0
Bit 28 (reserved)0 transmit as 0
Bit 29 (dir/out) 1 OUT — propellant leaves tank
Bit 30 (settled) 0 PAID — burn complete
Bit 31 (debit) 1 DEBIT — tank account debited
Bit 32 (compound)0 flat value — simple record
Bits 33–36 (arch) 0000 Source-to-Sink — tank → thruster
Bit 37 (dir echo)1 OUT — matches bit 29 ✓ VALID
Bit 38 (stl echo)0 PAID — matches bit 30 ✓ VALID
Bit 39 (complete) 0 FULL — no continuation
Bit 40 (ext byte) 0 no extension byte
────────────────────────────────────────────────────────
FLOW OUT MMH Tank 1 g 450
FLOW IN Thruster 7 Manifold g 450
────────────────────────────────────────────────────────
Archetype Source-to-Sink (0000) — direct transfer
Status Settled — quantity transferred and logged
Cross-layer check PASS — bit29=bit37, bit30=bit38
Wire size 5 bytes (Layer 3 record only)
────────────────────────────────────────────────────────

Conservation check. A session batch covers one mission phase. At batch close, the conservation invariant requires: sum of all FLOW OUT from all tanks + sum of all FLOW IN to all thrusters = 0 (signed). If the OME consumes 180 kg and 16 attitude thrusters together consume 12 kg over the phase, those 192 kg must appear as FLOW IN to propulsion components. Tank levels at phase end = tank levels at phase start − 192 kg. Any discrepancy is a non-zero Rounding Balance in Layer 2 — the protocol flags it before mission planning software reads a single record.

Cosmic Ray Fault Scenario — Bit 29 Flip
Nominal: bit29=1 (OUT) · bit37=1 (OUT) · cross-layer: PASS
Corrupted: bit29=0 (IN) · bit37=1 (OUT) · cross-layer: FAIL
 
Without BitLedger: transport CRC passes (single-bit undetected)
→ propellant recorded as ARRIVING at tank instead of leaving
→ mass balance error propagates silently into mission planning
 
With BitLedger: bit29 ≠ bit37 → cross-layer validation FAILS immediately
→ record rejected before posting → NACK sent → retransmit requested
→ mass balance preserved
BitLedger (100 burns/day)
500 bytes
JSON equivalent
~45,000 bytes

The reduction is structural. No decompression step. The decoder reads fixed bit positions and the record is decoded. On a deep-space link where bandwidth is measured in bits per second, 500 bytes vs 45,000 bytes is an operational constraint, not a convenience.

Deployment Scenario 2

Environmental Control & Life Support

02
Aerospace · Life Support Systems
ISS-Equivalent ECLSS — Atmosphere & Water Recovery
5 bytes / flow record
1-byte alert signal possible

System context. An ISS-equivalent ECLSS tracks three primary flows simultaneously: O₂ generation from the Oxygen Generation Assembly (OGA), CO₂ removal via the Carbon Dioxide Removal Assembly (CDRA), and water recovery through the Water Recovery System (WRS). Each process is governed by a different flow archetype. Multiple archetypes operate in the same session batch — this is the default operating mode for real life support systems, not an edge case.

O₂ Generation archetype
0101 Generation
Input from outside tracked system (electrolysis of water → O₂)
Crew metabolic archetype
0100 Loss/Dissipation
O₂ consumed; CO₂ exits to CDRA
Water recovery archetype
1000 Transformation
Waste water → potable water (form changes, mass conserved)
Quantity type: atmosphere
004 Pressure
mbar · D=1 · step=0.1 mbar

Single 5-byte record: O₂ partial pressure delta in one breathing cycle. The OGA generates enough O₂ to raise cabin partial pressure by 1.4 mbar (14 encoded at D=1, mbar × 10). This records one OGA output cycle — approximately 5 minutes of generation at nominal rate.

────────────────────────────────────────────────────────
BITLEDGER FLOW RECORD — O₂ GENERATION CYCLE
Session: ECLSS / OGA Subsystem (node 11)
Batch: Cycle 1440 / Unit: pressure (mbar × 10)
────────────────────────────────────────────────────────
Quantity type 004 (Pressure, mbar, D=1) · step = 0.1 mbar
Target value 1.4 mbar → N = 14 (mbar × 10)
Encoding S=8 · A=0 · r=14 · exact
Bits 1–17 (A) 0 0000 0000 0000 0000 A=0
Bits 18–25 (r) 0000 1110 r=14
Bit 26 (exact) 0 exact
Bit 27 0
Bit 28 0
Bit 29 (dir) 0 IN — pressure entering cabin atmosphere
Bit 30 (settled) 0 PAID — complete cycle
Bit 31 0
Bit 32 0
Bits 33–36 (arch) 0101 Generation/Input — OGA produces O₂
Bit 37 (echo) 0 IN — matches bit 29 ✓ VALID
Bit 38 (echo) 0 PAID — matches bit 30 ✓ VALID
Bit 39 0 FULL
Bit 40 0 no extension
────────────────────────────────────────────────────────
FLOW IN Cabin Atmosphere mbar +1.4
FLOW OUT OGA Output Node mbar +1.4 (environment source)
────────────────────────────────────────────────────────
Status Settled

Conservation invariant for atmosphere management. Across any closed batch period, the conservation invariant reads: O₂ generated = O₂ consumed by crew + O₂ stored in tank + O₂ lost to any detected leak. This is not a software check written in mission software — it is enforced by the protocol structure before the ECLSS controller processes a single record. A non-zero Rounding Balance at batch close is the signal that the atmosphere budget is not balanced. This detects leaks, sensor faults, and OGA malfunctions at the protocol layer.

ECLSS Conservation Invariant — Per Batch
O₂_generated (archetype 0101, FLOW IN to cabin) = +Σ(OGA records)
O₂_consumed (archetype 0100, FLOW OUT to null node) = −Σ(metabolic records)
O₂_stored (archetype 0110, FLOW OUT to O₂ tank) = −Σ(storage records)
 
Invariant: Σ(signed flows) = 0
Violation: Rounding Balance ≠ 0 → leak, fault, or sensor error flagged

CO₂ alert via Wave frame. When the CO₂ partial pressure crosses a threshold (above 5.3 mbar in the CDRA intake), the CDRA controller does not wait to assemble a full 5-byte record. It transmits a 4-byte Wave frame declaring Zone = CDRA, reading = 5.8 mbar, alert type = CO₂-HIGH. The receiver is in elevated alert mode before the full record is assembled. This is the Wave category in action — the full record follows as audit trail, but the alert arrives in a single Wave frame.

CO₂ THRESHOLD ALERT — WAVE FRAME (4 bytes)
Meta byte 1 0x0F = Wave · no ACK · complete · category mode · Priority Alert (1111)
Category 1111 Priority Alert — receiver enters elevated mode immediately
Payload Zone: CDRA · Reading: 58 (5.8 mbar × 10) · Type: CO₂-HIGH
Latency 4 bytes transmitted before full record assembled

Deployment Scenario 3

Satellite Power Settlement

03
Aerospace · Constellation Operations
40-Satellite LEO Constellation — Power Obligation Settlement
15 bytes / compound transfer
3-record chain, 92-min session

System context. A 40-satellite LEO constellation operates a power-sharing agreement. During eclipse periods (36 minutes per 92-minute orbit), eclipse-phase satellites draw power from battery stores. Sunlit satellites accumulate solar generation credit. The constellation settles these power obligations continuously — each orbital pass is one BitLedger session. The session covers all 40 satellites' records under a single CRC-15.

Obligation archetype
0010 Debtor-to-Creditor
Eclipse satellite owes sunlit satellite
Settlement archetype
0111 Repayment/Return
Prior obligation fulfilled on sunlit pass
Quantity type
002 Energy · Wh
SF=×1, D=1 · step=0.1 Wh
Session scope
One orbital pass
92 minutes · all 40 satellites

Multi-leg compound transfer. Satellite A (eclipse, node 01) cannot transmit directly to Satellite B (sunlit, node 12). It routes through Relay Satellite C (node 07). This three-leg transfer — A records obligation, relay acknowledges routing, B records receipt — is one logical transaction. The compound continuation marker 1111 links all three records. The 1111 code in the archetype field means "this record continues the preceding compound group." Together they are one event.

LEG
1/3
Record 1 — Obligation Incurred
Satellite A (node 01) records 12,847.50 Wh drawn from Satellite B reserve. Archetype 0010 (Debtor-to-Creditor). Status: Debt (bit 30=1). Compound continuation active (bit 39=1, partial).
Encoding: N=1,284,750 · A=5,018 · r=142 · Verify: 5,018×256+142=1,284,750/100=12,847.50 Wh ✓
LEG
2/3
Record 2 — Relay Routing (Continuation 1111)
Relay Satellite C (node 07) records forwarding of obligation from A to B. Archetype 1111 (Compound Continuation). Sub-type bits 37–38 = 00 (standard linked entry). This record has no independent conservation value — it is part of the compound event.
Bits 33–36: 1111 · Bits 37–38: 00 · Bit 39: 1 (partial, leg 3 follows)
LEG
3/3
Record 3 — Receipt Confirmed (Continuation 1111)
Satellite B (node 12) records receipt of 12,847.50 Wh obligation from A via relay C. Archetype 1111 (Compound Continuation). Sub-type bits 37–38 = 00. Bit 39=0 (FULL — compound event closed). CRC-15 covers all three records plus the full session.
Bits 33–36: 1111 · Bits 37–38: 00 · Bit 39: 0 (FULL — compound closed)
────────────────────────────────────────────────────────
COMPOUND POWER TRANSFER — 3-RECORD CHAIN
Session: Constellation Ops / Pass 1842 (node 01)
CRC-15 covers all 40 satellites in this orbital pass
────────────────────────────────────────────────────────
Record 1 (5 bytes) Archetype 0010 · Debt · Partial (1 of 3)
FLOW OUT Sat-B Power Reserve Wh 12,847.50
FLOW IN Sat-A Draw Account Wh 12,847.50
Status Debt — obligation recorded, not yet settled
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
Record 2 (5 bytes) Archetype 1111 · Relay routing · Partial (2 of 3)
FLOW OUT Relay-C Forward Buffer Wh 12,847.50
FLOW IN Sat-B Incoming Queue Wh 12,847.50
Sub-type Standard linked (bits 37–38 = 00)
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
Record 3 (5 bytes) Archetype 1111 · Receipt confirmed · FULL (3 of 3)
FLOW OUT Sat-B Confirmation Node Wh 12,847.50
FLOW IN Sat-A Obligation Ledger Wh 12,847.50
Compound closed Bit 39=0 · FULL · event complete
────────────────────────────────────────────────────────
Total wire cost 15 bytes for 3-leg compound transfer
Session coverage All 40 satellites · CRC-15 verifies entire pass
Bandwidth 40 satellites × ~5 records × 5 bytes = 1,000 bytes / pass

Deployment Scenario 4

Factory Floor Material Balance

04
Manufacturing · Automotive Stamping
Steel Coil to Door Panel — 5-Station Material Tracking
50,000 bytes / shift
JSON: ~40MB / shift

System context. An automotive stamping plant processes steel coil stock through five stations: Uncoil, Blank, Draw, Trim, and Pierce. Each station receives material from the prior station, transforms it, and passes the output forward. Scrap is generated at Blank (skeleton offcuts), Trim (edge waste), and Pierce (slug waste). Every station-to-station transfer is one BitLedger record. Every scrap event is the Rounding Balance field — the protocol has an explicit field for the net conservation error, which is exactly what scrap is.

Station receive archetype
0000 Source-to-Sink
Prior station → current station buffer
Transformation archetype
1000 Transformation
Steel coil → blank (form changes, mass conserved)
Scrap handling
Rounding Balance field
Layer 2 field — explicit protocol-level scrap register
Quantity type
001 Mass · grams
SF=×1000, D=0 → kg resolution

Station 2 (Blank): coil input to blank output. Station 2 receives 850 kg of steel coil from the uncoiler, blanks it into door panel blanks. Output = 781 kg of blanks. Scrap = 69 kg of skeleton offcuts. The conservation check: 850 kg in − 781 kg out − 69 kg scrap = 0. The 69 kg scrap appears in the Rounding Balance field of the Layer 2 batch header for this station's batch. The MES receives a record that has already verified its own conservation before it arrived.

────────────────────────────────────────────────────────
BITLEDGER FLOW RECORD — STATION 2 BLANK OPERATION
Session: Stamping Line A / Blank Station (node 02)
Batch: Shift 14 / Coil Lot 2847 / Unit: grams (mass)
────────────────────────────────────────────────────────
Quantity type 001 (Mass, g) · SF=×1000 · D=0
RECORD A — Coil input to blank station (Source-to-Sink)
Archetype 0000 Source-to-Sink
Target 850 kg = N=850,000 g
Encoding S=8 · A=3,320 · r=192
Verify 3,320×256+192=849,792+208... recalc: A=floor(850,000/256)=3,320, r=850,000−3,320×256=850,000−849,920=80
Corrected A=3,320 · r=80 · verify: 3,320×256+80=850,000 ✓
FLOW OUT Uncoiler Output Buffer g 850,000
FLOW IN Blank Station Input Queue g 850,000
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
RECORD B — Blank output to draw station (Transformation + Source-to-Sink)
Archetype 1000 Transformation (blanking process)
Output 781 kg blanks = N=781,000 g
Encoding S=8 · A=3,050 · r=200
Verify 3,050×256+200=780,800+200=781,000 ✓
FLOW OUT Blank Station (steel coil form) g 781,000
FLOW IN Blank Station (door blank form) g 781,000
────────────────────────────────────────────────────────
Layer 2 Rounding Balance = 69,000 g = 69 kg skeleton scrap
Conservation check850,000 in − 781,000 out − 69,000 scrap = 0 ✓
MES decision PASS — batch accepted before MES reads first record
────────────────────────────────────────────────────────

If the scrap weight reported by the Blank station's scale disagrees with the difference between input and output records, the conservation check fails before the batch reaches the MES. The discrepancy is flagged at the wire level — no separate reconciliation run is required. At 10,000 parts per shift, the complete material tracking log is 50,000 bytes of BitLedger records (10,000 parts × 5 records/part chain × 1 byte overhead average). The JSON equivalent of the same event data is approximately 40MB.

BitLedger (10K parts/shift)
50,000 bytes
JSON equivalent
~40,000,000 bytes

Deployment Scenario 5

IoT Resource Networks

05
Infrastructure · Smart Building
200-Sensor Building — Energy, Water & HVAC Zone Accounting
2,600 bytes / hour
JSON: ~320,000 bytes / hour

System context. A 200-sensor smart building tracks energy consumption, water flow, and HVAC delivery across 40 zones. Each sensor operates on a three-tier transmission schedule: 1-byte Pure Signal heartbeat every 60 seconds for liveness; 4-byte Wave frame for threshold alerts; full 5-byte BitLedger record once per hour for formal accounting. The protocol tier is selected by the sensor's state — normal operation needs only the heartbeat; anomalies escalate to Wave or Record automatically.

Heartbeat (1 byte)
0x40 Pure Signal
Wave · ACK req · zone reporting in
Threshold alert (4 bytes)
Wave frame · cat 1111
Zone · reading · alert type
Hourly record (5 bytes)
Full BitLedger record
T1S timestamp · conservation checked
Context Declaration
Category 1101
One declaration → 50 records inherit context

Heartbeat protocol. Each sensor transmits 0x40 every 60 seconds. This is Meta byte 1 alone: Wave mode, ACK request, complete, basic treatment, no flags. One byte declares "I am here, acknowledge me." At 200 sensors, heartbeat traffic is 200 bytes per minute — 12,000 bytes per hour — across the entire building liveness network. The building controller knows within 60 seconds if any sensor has dropped.

Enhancement Grammar context declaration. Before transmitting 50 zone-B energy records, the HVAC controller transmits one Category 1101 Context Declaration Enhancement byte. This declares the context — Zone-B, Energy, HVAC — once. The 50 subsequent records inherit that context without re-stating it in each record. This is the Enhancement Grammar's context accumulation mechanism: declare once, apply to the entire subsequent block. The 50 records cost 250 bytes instead of the 350 bytes they would cost if each record included a full zone declaration.

────────────────────────────────────────────────────────
BANDWIDTH ACCOUNTING — 200-SENSOR BUILDING
Per-hour transmission budget
────────────────────────────────────────────────────────
Heartbeat (1B/60s) 200 sensors × 60 pulses/hr = 12,000 bytes/hr
Hourly record (5B) 200 sensors × 1 record/hr × 5 bytes = 1,000 bytes/hr
Context Decls (1B) 4 declarations (energy/water/HVAC/power) = 4 bytes/hr
Wave alerts (4B) Variable — 10 alerts/hr typical = 40 bytes/hr
─────────────────────────────────
Total ~13,044 bytes/hr (liveness + accounting + alerts)
Full records only 200 × 13 bytes (with timestamp) = 2,600 bytes/hr
────────────────────────────────────────────────────────
JSON equivalent ~320,000 bytes/hr (same event data)
Reduction factor ~123× (structural, not compressive)
────────────────────────────────────────────────────────

Anomaly records with T1S timestamp. When an energy sensor records an anomaly — consumption spike, sudden drop — it transmits a full BitLedger record with a T1S time component (Unix epoch seconds, 4 bytes). The T1S block attaches to the record via the component sequence in BitPads v2: Meta byte 2 declares the Time component present, and the 4-byte T1S block follows immediately after the Layer 3 record. Total anomaly record: 13 bytes (Meta 1 + Meta 2 + Layer 1 session header omitted on continuation + Layer 3 + T1S). The exact timestamp is preserved for maintenance correlation without any separate logging system.

Deployment Scenario 6

Mars Colony Supply Chain

06
Deep Space · Autonomous Operations
100-Person Mars Settlement — 8-Module Habitat Supply Chain
500 bytes / daily batch
Fits single radio packet

The fundamental problem. Earth-to-Mars communication latency is 7 to 30 minutes one-way depending on orbital position. Every supply chain decision — O₂ generation rate, food ration allocation, water recovery priority, spare part scheduling — must be made locally. There is no Earth-side database query with a 20-minute turnaround. The conservation enforcement must live in the colony. The protocol must work without a network connection to its originating authority.

BitLedger is the on-colony ledger. The same 40-bit records that enforce conservation on a terrestrial factory floor enforce conservation in Habitat Module 4. The invariant does not require a server. It is structural — a record that violates conservation is rejected at encoding time, before it reaches the habitat management system, whether or not Mars is in conjunction with Earth.

Sender ID structure
32-bit / 8+6+18 split
8 bits habitat module · 6 bits supply category · 18 bits item ID
Inter-module archetype
0000 Source-to-Sink
Module 3 O₂ to Module 7 habitat
Resupply archetype
0101 Generation/Input
Earth shipment enters colony system
Domain
0 10 Hybrid
Physical mass + USD-equivalent Earth cost in same session

Identity encoding for 8 habitat modules. The 32-bit Sender ID encodes the full addressing hierarchy in a single field. Bits 31–24: habitat module (0–7, 3 bits used). Bits 23–18: supply category (O₂=0, H₂O=1, Food=2, Power=3, Parts=4, Medical=5). Bits 17–0: individual item ID within category (up to 262,143 distinct items per category per module). All 8 modules × 6 categories × 262,143 items = 12.6 million addressable supply items within the 32-bit sender space.

Hybrid domain: physical and financial in one session. When domain bits 3–4 = 10 (Hybrid), the session contains both physical flow records and financial obligation records. A resupply shipment from Earth has physical mass (tracked with archetype 0101, quantity type 1, grams) and financial cost (tracked with Debtor-to-Creditor archetype, currency code USD, per-kg launch cost). One session covers both the physical inventory update and the mission cost accounting. The decoder distinguishes record type by the archetype code — physical archetypes and financial account pair codes occupy non-overlapping ranges in the hybrid interpretation.

────────────────────────────────────────────────────────
MARS COLONY DAILY SUPPLY BATCH — EXAMPLE SUMMARY
Session: Colony Sol 847 / Habitat 4 (node 0x41000001)
Domain: Hybrid (bits 3–4 = 10)
────────────────────────────────────────────────────────
Record 1–12 O₂ inter-module transfers (archetype 0000)
Record 13–20 H₂O recovery cycles (archetype 1000 Transformation)
Record 21–35 Food ration allocations (archetype 0001 Parent-to-Child)
Record 36–50 Power distribution (archetype 1001 Distribution)
Record 51–78 Parts reservations (archetype 0110 Reservation/Escrow)
Record 79–88 Medical supply draws (archetype 0000 Source-to-Sink)
Record 89–96 Earth resupply receipt (archetype 0101 Generation/Input)
Record 97–100 Financial obligations for resupply (USD cost accounting)
────────────────────────────────────────────────────────
Total records 100 records × 5 bytes = 500 bytes
Radio packet Fits single 512-byte CCSDS packet to Earth
Conservation All 6 supply categories checked before transmission
Earth latency 7–30 min — irrelevant: conservation enforced locally
────────────────────────────────────────────────────────

All 16 flow archetypes are active in a Mars colony deployment. Internal module transfers use Source-to-Sink. Crew ration allocations use Parent-to-Child. Borrowed supplies between modules use Debtor-to-Creditor. Atmosphere recycling uses Transformation. Earth shipments use Generation/Input. Emergency reserves use Reservation/Escrow. Resupply debt from prior shipments uses Repayment/Return. This is not a contrived mapping — it is the natural vocabulary of any complex supply chain, and the 16 archetypes were derived from exactly this class of system.

Implementation Reference

Implementation Checklist

What a real engineering team needs to deploy BitLedger Universal Domain. These are not aspirational steps — each is a specific configuration decision with a specific bit field that carries it on the wire.

Step Task Specific Action Wire Location
01 Set domain bits. Engineering domain must be declared in Layer 1 before any records are transmitted. Set Layer 1 bits 3–4 = 01. Bit 2 = 0 (version 1). Full opening 4 bits: SOH=1, ver=0, dom=01. L1 bits 2–4
02 Select flow archetypes. Map each canonical relationship in your system to one of the 16 universal archetypes. Every flow your system tracks must have an archetype assignment before encoding begins. Document: source flows → 0000, obligation flows → 0010, generation events → 0101, transformation processes → 1000, compound multi-resource events → 1111. L3 bits 33–36
03 Choose Quantity Type Code. Select the 6-bit index for your primary conserved scalar. If your system tracks multiple quantity types in one session, plan the control byte sequence for switching. Mass=001, Energy=002, Pressure=004, Thrust=008. For mixed batches: control byte 0 001 QQQQ switches quantity type to index QQQQ between records. L2 bits 36–41
04 Set Scaling Factor and Decimal Position. Choose the SF and D that give you the precision step your instruments require. Precision step = 1 unit / 10^D. Mass in grams, integer: SF=×1, D=0. Mass in kg, integer: SF=×1000, D=0. Energy in Wh to 0.01 precision: SF=×1, D=2. Encode: N = value × 10^D / SF. L2 Scaling Factor · Decimal Position
05 Implement CRC-15 on Layer 1. The CRC-15 covers the complete Layer 1 block (sender identity, permissions, domain, session defaults). It is computed once per session open and verified once per session accept. Polynomial: x^15 + x + 1. Input: Layer 1 bytes excluding the 15-bit CRC field itself. Embed result in L1 CRC field. Reject session if CRC fails on receive. L1 CRC-15 field (15 bits)
06 Implement conservation check at batch close. At every batch close control record, verify: sum of all signed flow values in the batch = 0 (within Rounding Balance tolerance). Maintain running signed sum. Positive for FLOW IN (bit 29=0), negative for FLOW OUT (bit 29=1). At close: if |sum| > Rounding Balance × precision step, reject batch. L2 Rounding Balance + batch close control record
07 Implement cross-layer validation. Every record carries direction and status flags in two locations. Disagreement is a protocol error detectable without a separate checksum field. On every received record: verify bit 29 = bit 37. Verify bit 30 = bit 38. Verify: NOT (bit 26=0 AND bit 27=1) — invalid rounding state. Any failure → reject record, NACK. L3 bits 29, 30, 37, 38, 26, 27
08 Choose signal slot positions for alerts. If your system needs sub-record alert signalling (threshold crossing, emergency status), assign Enhancement signal slot positions P1–P13 for alert bytes. P1 = session open enhancement (priority escalation). P5 = batch-boundary alert. P9 = record-level signal. Declare active slots in Layer 1 Setup byte. Wave frame (4 bytes) for immediate alerts without a full record. L1 Setup byte · Enhancement signal slots P1–P13
09 Plan compound mode if needed. Any event that simultaneously affects multiple resource types (a burn consuming propellant and generating thermal load) requires compound mode. Declare it at session open. Set L1 bit 11 = 1 (compound mode active for session). First record: bit 39=1 (partial). Subsequent records: archetype bits 33–36 = 1111. Final record: bit 39=0 (full). Sub-type in bits 37–38. L1 bit 11 · L3 bits 33–36, 37–38, 39
10 Optionally add Enhancement Grammar. For systems with typed status events (sensor categories, zone declarations, phase transitions), use Category 1101 Context Declaration to set context once per block of similar records. Transmit Category 1101 Enhancement byte before each block of records sharing the same context. Receivers update their context register. Subsequent records omit redundant context fields. Net saving: 1 byte per record in declared scope. Wave category 1101 · Enhancement sub-protocol

Transport compatibility. BitLedger records are transport-agnostic. The 40-bit record is a self-contained payload that carries inside any transport without modification: CCSDS (spacecraft telemetry), DTN Bundle Protocol (deep space delay-tolerant networking), MQTT (IoT edge), raw RF (point-to-point embedded), or Ethernet/UDP (factory floor). The transport handles routing. BitLedger handles semantic integrity. The CRC-15 validates the session on reconnect regardless of how long the link was interrupted.

Format Comparison by Deployment

System Volume BitLedger JSON equivalent Reduction
Spacecraft propellant (100 burns/day) 100 records 500 bytes ~45,000 bytes 90×
Satellite constellation (40 sats / pass) ~200 records / pass 1,000 bytes ~90,000 bytes 90×
Factory stamping line (10K parts / shift) 50,000 records 50,000 bytes ~40,000,000 bytes 800×
Smart building (200 sensors / hour) 200 records + 12K heartbeats ~13,000 bytes ~320,000 bytes ~25×
Mars colony daily batch 100 records 500 bytes ~80,000 bytes 160×

The reduction is structural, not compressive. No decompression step. No schema lookup. The decoder reads fixed bit positions. On any link constrained by bandwidth, latency, or power — which describes every deployment above — the encoding density is an operational requirement, not an optimisation.