BitLedger Universal Domain v1.0 · Companion to BitLedger Protocol v3.0

Any Conserved
Scalar

Financial accounting and physical conservation are the same algebra applied to different quantities. The wire format does not change.

The same 40-bit record that encodes a monetary transaction can carry 450 kg of propellant flowing from Tank Assembly to Main Engine Thruster Array — because both are applications of the same conservation law.

Double-entry accounting is not a bookkeeping convention. It is a conservation law. Every transaction records a quantity leaving one account and arriving at another. The sum of all signed flows in any valid set of entries is zero. This is the same algebraic invariant that governs current flow in electrical networks, mass balance in chemical processes, and momentum transfer in mechanical systems.

Kirchhoff's Current Law — sum of currents at any node equals zero — is double-entry balance applied to electrical current. The same principle governs mass in a pipe network, heat in a thermal system, data packets in a buffer, and watt-hours in a satellite power constellation. BitLedger encodes this invariant at the wire level for any domain.

Key insight: What changes across domains is the semantic interpretation of two fields: the 4-bit relationship matrix (account pair in financial mode, flow archetype in engineering mode) and the 6-bit quantity type code (currency in financial mode, physical unit in engineering mode). Every other bit in the 40-bit record is domain-agnostic by construction. A financial decoder reading an engineering record sees valid wire structure — it simply loads a different interpretation table.

Kirchhoff's Current Law

∑(I_in) − ∑(I_out) = 0

All currents at any node
sum to zero.

Electrical networks · 1845.

Double-Entry Accounting

∑(Debits) = ∑(Credits)
∑(+V_i) + ∑(−V_i) = 0

Same invariant applied
to monetary quantities.
Venetian merchants · 1494.

BitLedger Batch

∑(signed flows) = 0
(mod precision step)

Enforced at wire level
before application
processes any record.

These three statements are the same conservation principle expressed in different domains. Any system governed by a conservation law is a natural candidate for BitLedger records — not as an approximation, but as an exact fit. The wire format does not change across domains.

Layer 1 · Bits 3–4

Domain Declaration

The receiver learns the semantic context of the entire session within the first four bits it ever receives. Bit 1 is always 1 (SOH). Bit 2 carries the wire format version. Bits 3–4 carry the domain code. By the time the receiver has processed four bits it knows whether to interpret subsequent records as financial entries, physical flow records, a hybrid of both, or a custom-declared domain.

Layer 1 · Byte 1 · Bits 1–8 — Domain declaration in bits 3–4

1 1 SOH

2 0 Ver.

3 0 Dom
MSB

4 1 Dom
LSB

5 0 Obs.

6 0 Act.

7 0 Ovr.

8 0 Proxy

Mode / Domain Control Permission Flags Shown: Engineering domain — bits 3-4 = 01

Domain Code Table

Financial

Default. Full backward compatibility with BitLedger v3.0. Account pairs interpret as financial categories. Currency Code field = currency index.

Engineering

Universal Domain (this document). Account pairs interpret as universal flow archetypes. Currency Code field = quantity type index. Wire format byte-for-byte identical to Financial.

Hybrid

Both matrices active simultaneously. Financial cost accounting and physical mass or energy flow in the same session. Record-level disambiguation via extension byte.

Custom

User-defined domain. Extension block transmitted immediately after Layer 1 close, before first batch. Receiver waits for declaration before processing any records.

Switching domain changes only the semantic interpretation of the 4-bit relationship field and the 6-bit quantity type field. The wire format version (bit 2), all identity fields, all session defaults, the value encoding formula, the CRC-15, the cross-layer validation rules, and the compound continuation mechanism are identical across all four domains.

Bits 2–4	Domain	Relationship Field	Quantity Field	Decoder Action
`0 00`	Financial (v1)	Account pair codes — Protocol v3.0	Currency index	Load financial labels and currency table
`0 01`	Engineering (v1)	Universal flow archetypes — this document	Quantity type index	Load archetype labels and physical unit table
`0 10`	Hybrid (v1)	Both matrices active	Per-record via extension byte	Load both; disambiguate per record
`0 11`	Custom (v1)	User-declared	User-declared	Wait for extension block after Layer 1
`1 xx`	Version signal	—	—	Read version control byte after Layer 1 before batches

4-Bit Relationship Field · Engineering Domain

16 Universal Flow Archetypes

These 16 archetypes are not domain-specific. They are the fundamental ways that quantities relate between any two entities in any engineered system.

In financial mode the 4-bit pair field encodes which two account categories are involved in a transaction. In engineering mode the same 4 bits encode the relationship archetype between any two nodes, subsystems, or entities in the tracked system. A spacecraft subsystem consuming propellant, a satellite accruing a power debt, a factory station transferring work-in-process, and a microcontroller spending battery charge all express one of these 16 archetypes.

Click any row to expand full details, activation conditions, and an annotated 5-byte record.

Code	Archetype	Canonical Meaning	Example Systems
`0000`	Unclassified / Custom	User-defined or not yet classified	Any custom deployment	▾
Description Reserved for user-defined relationship types or flows not yet classified during development. Receiver must not apply conservation validation without knowing the flow direction convention declared for this code in the session's custom extension block. Activation Condition Bits 33–36 = `0000`. Use only when no standard archetype adequately describes the relationship, or during prototyping before the final archetype assignment is known. Record Bits 33–36 0 0 0 0
`0001`	Source-to-Sink	Canonical directional flow between two distinct nodes	Pipe / wire / supply chain / tank-to-thruster	▾
Description Direct one-way transfer of a conserved quantity from a source node to a sink node. The most common archetype. The source is debited; the sink is credited. Direction bit = Out. Status = Settled (transfer complete) or Debt (delivery pending). Activation Condition Two clearly distinct nodes where quantity unambiguously originates at one and terminates at the other. No transformation, no obligation structure, no distribution fan-out. Examples Fuel tank to thruster. Battery to payload. Upstream buffer to downstream processor. Solar panel output to battery charge bus. Factory warehouse to assembly station. Record Bits 33–36 0 0 0 1 Bit 29 = 1 (Out), Bit 37 = 1 (must match), Bit 30 = 0 (Settled).
`0010`	Debtor-to-Creditor	Obligation incurred — quantity owed, not yet transferred	Power debt / delivery pending / service obligation	▾
Description Records that a quantity is owed but not yet transferred. The debtor node owes the quantity to the creditor node. Bit 30 = 1 (Debt). The obligation exists in the system's accounting until settled by a Creditor-to-Debtor (0011) record or voided by a Correction (1110). Activation Condition Quantity has been drawn or committed but physical transfer is not yet complete, or the accounting entry precedes physical transfer by design (obligation-first recording). Examples Satellite A draws 12,847.50 Wh from Satellite B under a power-sharing agreement; repayment pending. Component delivery committed but not yet arrived at factory station. Record Bits 33–36 0 0 1 0 Bit 30 = 1 (Debt), Bit 38 = 1 (must match Bit 30).
`0011`	Creditor-to-Debtor	Obligation settlement — prior debt fulfilled	Power repayment / debt closure / service delivery	▾
Description The counterpart to Debtor-to-Creditor. Records the physical transfer that settles a prior obligation. The creditor delivers the quantity; the debtor's obligation is extinguished. Conservation invariant requires the settlement value to match the obligation value within rounding tolerance. Examples Satellite A returns 12,847.50 Wh to Satellite B, closing the power debt opened by archetype 0010. Factory station delivers committed components; pending obligation cleared from batch. Record Bits 33–36 0 0 1 1 Bit 30 = 0 (Settled — debt now closed).
`0100`	Generation	Quantity created by a process — enters the tracked system	Solar panel / electrolysis / resupply docking	▾
Description Quantity enters the system boundary from a source node that is part of the system (a process or conversion device). The source node is the generation process; the sink node is the system's internal store or bus. For external sources, use External Input (1001). Examples Solar panel generating power: source = Solar Array Assembly, sink = Power Bus. Electrolysis producing O₂: source = ECLSS Electrolyser, sink = Atmosphere O₂ Store. Photovoltaic output to battery charge. Record Bits 33–36 0 1 0 0
`0101`	Consumption	Quantity destroyed in a process — exits the tracked system	Propellant burn / power draw / reagent use	▾
Description Quantity is destroyed or converted to an untracked form within a process node. The source node is the internal store; the sink node is the consumption process (thruster, reactor, heater). The quantity leaves the tracked system without appearing elsewhere in the batch. Examples Hydrazine propellant burn: source = Propellant Tank, sink = Main Engine (consumed). Battery discharge to payload electronics. Reagent consumed in a chemical process. Electrical power dissipated as heat in a resistive load. Record Bits 33–36 0 1 0 1
`0110`	Distribution	One source node to many sink nodes	Power bus / broadcast / multicast / manifold	▾
Description A single source distributes quantity to multiple sinks. Each Distribution record represents one source-to-sink leg. Conservation requires that all legs in the batch sum to the total quantity leaving the source. Use Compound Continuation (1111) to link legs of the same distribution event. Examples Power bus delivering to multiple subsystems simultaneously. Network packet multicast to subscriber list. Hydraulic manifold supplying multiple actuators. Mission control broadcasting power budget to rover subsystems. Record Bits 33–36 0 1 1 0
`0111`	Transformation	Quantity changes form within a node	Combustion / stamping / chemical reaction / data encode	▾
Description A quantity enters a node in one form and leaves in a different form. The node itself is the transformation agent. Conservation holds across the transformation: mass in = mass out (plus scrap/loss recorded separately). Typically used with Compound Continuation to record both input and output forms in one event. Examples Factory press: 50 kg steel billet in → 48.2 kg stamped part + 1.8 kg scrap. Chemical reactor: reagent mass in → product mass out. Encoder: raw data in → compressed data out (same KB count if lossless). Combustion chamber: propellant mass in → thrust impulse (use compound with Generation). Record Bits 33–36 0 1 1 1
`1000`	Aggregation	Many source nodes to one sink node	Sensor fusion / tributary merge / collection	▾
Description Multiple sources contribute to a single sink. Each Aggregation record represents one source leg. Conservation requires that all legs in the batch sum to the total quantity arriving at the sink. The mirror image of Distribution (0110). Examples Multiple sensor nodes feeding one gateway processor. Tributary rivers to main storage reservoir. Several production lines feeding one packing station. Multiple charge sources to a shared battery bank. Record Bits 33–36 1 0 0 0
`1001`	External Input	Quantity enters from outside the system boundary	Resupply / environmental ingress / signal reception	▾
Description Quantity arrives from a node that is outside the tracked system boundary. The source node is external (environment, supplier, upstream system). Use when the origin is beyond the system's accounting scope. Contrast with Generation (0100) where the source is an internal process node. Examples ISS resupply docking: propellant arrives from launch vehicle (external). Solar irradiance entering a thermal model. Raw material delivery from supplier to factory. Incoming satellite uplink from ground station. Record Bits 33–36 1 0 0 1
`1010`	External Output	Quantity exits through the system boundary	Ejection / exhaust / downlink / delivery to customer	▾
Description Quantity departs to a node outside the tracked system boundary. The sink is external. Contrast with Consumption (0101) where the sink is an internal process that destroys the quantity. Here the quantity is delivered, not destroyed — it simply leaves scope. Examples Spacecraft venting waste gas to space. Factory finished goods shipped to customer. Satellite transmitting data downlink (KB leave the onboard buffer). Power exported to external grid from a prosumer node. Record Bits 33–36 1 0 1 0
`1011`	Internal Transfer	Flow between tracked sub-nodes within the same entity	Tank crossfeed / cache-to-register / module handoff	▾
Description Quantity moves between two sub-nodes within the same parent entity. No net change to the parent entity's total; the conservation invariant holds because both sub-nodes are tracked. Use the Sub-Entity ID field to distinguish the sub-nodes at record level. Examples Tank A crossfeed to Tank B within same spacecraft. CPU register to L1 cache. Assembly sub-station A to sub-station B within one factory cell. Charge transferred between battery bank modules. Record Bits 33–36 1 0 1 1
`1100`	Accumulation	Storage increasing — quantity flowing into a store	Tank filling / battery charging / buffer loading	▾
Description The net state of a store is increasing. Use when the emphasis is on the store's growing inventory rather than the source-to-sink directional flow. Often paired with State Commit (1101) records that snapshot the resulting stored level after accumulation. Examples Propellant tank filling during resupply. Battery charging from solar array. ISS water recovery tank accumulating recovered water. Onboard data buffer accumulating incoming sensor readings. Record Bits 33–36 1 1 0 0
`1101`	Depletion	Storage decreasing — quantity flowing out of a store	Tank draining / battery discharge / buffer draining	▾
Description The net state of a store is decreasing. The store is the source; the consumer or loss node is the sink. The mirror image of Accumulation (1100). Conservation requires the depletion to appear as an equal inflow somewhere else in the batch. Examples Propellant tank draining during a burn sequence. Battery discharging to power payload during eclipse. Buffer transmitting queued packets to downlink. Coolant reservoir draining to active cooling loop. Record Bits 33–36 1 1 0 1
`1110`	Recycling / Recovery	Output of a process returns as input — closed loop	Water recovery / heat recapture / regenerative braking	▾
Description Quantity that left the process as waste or output is recovered and re-enters as usable input. The source node is the recovery device; the sink node is the upstream input store. The closed-loop nature means the system's total inventory is preserved rather than depleted by that flow. Examples ISS ECLSS water recovery: condensate recovered and returned to potable water store. Regenerative braking: kinetic energy recovered to battery. Heat exchanger: waste heat recovered into thermal storage. Closed-loop coolant system recirculating. Record Bits 33–36 1 1 1 0
`1111`	Compound Continuation	This record continues a preceding compound group	Multi-stage burn / simultaneous flows / multi-leg transfer	▾
Description Marks a record as the continuation of a compound event opened by the preceding record (which had Bit 39 = 1, Partial). The 1111 code in bits 33–36 signals that this record does not stand alone — it must be interpreted as part of the compound group. Bits 37–38 carry the sub-type (standard continuation, override, etc.). Activation Condition Layer 1 bit 11 = 1 (compound mode active for session). The preceding record had bit 39 = 1 (Partial — compound continuation follows). This record uses 1111 to identify its role in the group. Examples Engine firing consuming propellant (Record 1, Source-to-Sink) simultaneously creates a thermal load obligation on life support (Record 2, Debtor-to-Creditor, archetype 1111). Satellite power settlement across three legs — each leg after the first is a Compound Continuation. Record Bits 33–36 1 1 1 1 Bits 37–38 = sub-type. Bit 39 = 0 (Full) closes the compound group.

Layer 2 · Bits 36–41 · Engineering Domain

Quantity Type Codes

In financial mode Layer 2 bits 36–41 carry a 6-bit currency index. In engineering mode the same field carries a Quantity Type Code (QTC) — a 6-bit index into a table of physical unit categories. The field width is unchanged: 64 possible codes, seeded with standard physical and relational unit categories.

The 12-bit "currency" field in Layer 2 is interpreted as: lower 6 bits = QTC (quantity type), upper 6 bits = reserved/precision modifier. The QTC tells the decoder which physical unit the value block represents. The Scaling Factor (SF) and Decimal Position (D) then set magnitude and precision within that unit.

Indices 0–15 · Core Physical

0x00 – 0x0F

0 — Session default (declared in Layer 1)
1 — Mass · natural unit: grams · D=0
2 — Energy · natural unit: watt-hours · D=2
3 — Data volume · natural unit: kilobytes · D=0
4 — Pressure · natural unit: millibars · D=1
5 — Temperature delta · millidegrees C · D=0
6 — Time duration · milliseconds · D=0
7 — Electrical charge · mAh · D=2
8 — Force / thrust · millinewtons · D=0
9 — Bandwidth · kbps · D=0
10 — Signal strength · dBm×100 offset · D=0
11 — Radiation dose · micrograys · D=0
12 — Angular momentum · milli-Nms · D=2
13 — Fluid volume · millilitres · D=0
14 — Service obligation · minutes · D=2
15 — Resource units · user-defined

Indices 16–62 · User-Defined

0x10 – 0x3E

47 codes available for deployment-specific unit categories
Declared at session open via Custom Domain Extension Block
Examples: specific propellant types, payload-specific metrics, mission resource scores, contract units
Each declaration specifies: index, unit label, default D, signed convention (if applicable)

Index 63 · Multi-Quantity

0x3F

Mixed-unit batch active
Per-record quantity type via control byte 0 001 QQQQ before each record
Used when a single batch spans multiple physical unit categories

Scaling Examples

The decode formula Real Quantity = (N × SF) / 10^D is domain-agnostic. SF and D set magnitude and precision within the QTC's natural unit.

450 kg propellant

QTC=1 (mass, grams) · SF=×1000 · D=0

N=450 → (450 × 1000) / 1 = 450,000 g = 450 kg

12,847.50 Wh energy

QTC=2 (energy, Wh) · SF=×1 · D=2

N=1,284,750 → (1,284,750 × 1) / 100 = 12,847.50 Wh

8,192 KB data

QTC=3 (data, KB) · SF=×1 · D=0

N=8,192 → (8,192 × 1) / 1 = 8,192 KB

−73.50 dBm signal strength

QTC=10 (signal, dBm×100 offset) · stored = (dBm+100)×100

N=2,650 → 2,650/100 − 100 = −73.50 dBm

Maximum physical quantity: At SF×1,000,000,000 and D=0 with QTC=1 (mass, grams), N_max = 33,554,431 → Q_max = 33,554,431 metric tonnes in a single 40-bit record. This exceeds the mass of the International Space Station by a factor of approximately 75 million.

Engineering Integrity · Batch Level

The Conservation Invariant

For every batch: Σ(signed scalar flows) = 0. The protocol enforces this at the wire level — if the balance fails, the encoder rejects the batch before transmission.

In financial mode the batch conservation check confirms that debits equal credits. In engineering mode it confirms that the tracked quantity is conserved across all flows in the batch. The algebraic invariant is identical — only the domain interpretation changes. If propellant leaves Tank A, it must arrive somewhere. If it does not, the batch balance is non-zero. The protocol detects this without any application-level audit.

Mass balance

mass_in = mass_out + mass_stored

Any non-zero batch balance ⟹ unaccounted flow. Flags leak or sensor fault.

Energy balance

energy_generated = energy_consumed + energy_stored + energy_lost

Loss recorded via Consumption (0101) or External Output (1010) with environment sink.

General form (any conserved scalar)

∑(FLOW OUT values) = ∑(FLOW IN values)

∑(signed flow values) = 0 (within rounding tolerance)

Enforcement Mechanisms

Three mechanisms enforce the invariant at different levels:

The double-entry structure of every 40-bit record — each record encodes both sides of a flow simultaneously.
The Rounding Balance field in Layer 2 — declares net conservation error for the batch. Acceptable tolerance = precision step × Rounding Balance value.
The batch close control record count — confirms all records arrived. A count mismatch signals an incomplete batch before any records are posted.

Worked Mass-Balance Batch — Pseudocode

Scenario · Spacecraft propellant transfer and burn · 3 records

BATCH OPEN — QTC=1 (mass, grams), SF=×1000, D=0

RECORD 1  Source-to-Sink (0001)
          Tank-A → Tank-B crossfeed (Internal Transfer used here
          would also be valid; Source-to-Sink when tanks are
          distinct accountability nodes)
          N = 200,000 g  →  Flow OUT Tank-A  = +200,000 g
                            Flow IN  Tank-B  = −200,000 g

RECORD 2  Consumption (0101)
          Tank-B → Main Engine burn
          N = 180,000 g  →  Flow OUT Tank-B  = +180,000 g
                            Flow IN  Engine   = −180,000 g
                            (engine consumes; exits tracked system)

RECORD 3  Accumulation (1100)
          Tank-B net state after crossfeed minus burn:
          remaining in Tank-B = 200,000 − 180,000 = 20,000 g
          State Commit logged via archetype 1101 snapshot.

BATCH CLOSE
  Signed sum: (+200,000 − 200,000) + (+180,000 − 180,000) = 0 ✓
  Rounding Balance = 0. Conservation invariant HOLDS.
  If any record were missing: sum ≠ 0 → batch REJECTED.

Conservation Tolerance in Physical Systems

Physical measurements have instrument resolution limits. A fuel flow sensor accurate to 1 gram cannot verify conservation to sub-gram precision. The Rounding Balance field and Decimal Position together define the acceptable conservation tolerance:

Acceptable tolerance = Precision Step × Max Rounding Balance

Example: QTC=1 (mass), SF=×1, D=0 → Precision Step = 1 gram

Rounding Balance = 3 → Acceptable tolerance = 3 grams

If actual error exceeds tolerance → Rounding Balance = 1000 (escape)

Receiver flags anomalous conservation error for investigation.

Annotated Records · Full 40-Bit Encoding

Worked Examples

Four complete engineering records with full field annotation. All use wire format v1, engineering domain (bits 2–4 = 0 01).

Example 01 Spacecraft Propellant Burn

Propulsion subsystem flows 450 kg (450,000 grams) from Tank Assembly to Main Engine Thruster Array. Archetype: Source-to-Sink (0001). Quantity Type = 1 (mass, grams). SF=×1000, D=0. Status = Settled. Exact.

40-bit record — bytes 1–5 — propellant burn 450,000 g

1–17 0000001 1011011 101 A = 1,757

18–25 01011000 r = 88

26 0 Exact

27 0 Rnd.

28 0 Flat

29 1 Out

30 0 Settl.

31 1 Debit

32 0 Flat

33–36 0001 Src→Snk

37 1 Out✓

38 0 Settl✓

39 0 Full

40 0 No Ext

Value Block (A, r) Status / Direction Flags Archetype Field Control

─────────────────────────────────────────────────────

BITLEDGER FLOW RECORD

Session : Artemis IV / Propulsion Sub (node 03)

Batch : Phase 02 / Event 007 / Unit: grams (mass)

─────────────────────────────────────────────────────

FLOW OUT Propellant Tank Assembly g 450,000

FLOW IN Main Engine Thruster Array g 450,000

─────────────────────────────────────────────────────

Archetype Source-to-Sink — direct transfer

Status Settled — quantity transferred and logged

Precision Exact

Encoding A=1757 r=88 → (1757×256)+88 = 450,000 g ✓

Bit 29 = Bit 37 = 1 — cross-layer validation PASS

Bit 30 = Bit 38 = 0 — cross-layer validation PASS

─────────────────────────────────────────────────────

Example 02 Solar Panel Power Generation

Solar array generates 2.4 kWh during one orbital daylight period. Archetype: Generation (0100). QTC=2 (energy, Wh). SF=×1, D=1. N=24 → (24×1)/10 = 2.4 Wh — or more practically: D=2, N=240 → 2.40 Wh. For a larger generation event showing D=1, SF=×1: N=24 → 2.4 Wh.

─────────────────────────────────────────────────────

BITLEDGER FLOW RECORD

Session : LEO Sat-07 / Power System (node 02)

Batch : Orbit 089 / Event 001 / Unit: watt-hours

─────────────────────────────────────────────────────

FLOW OUT Solar Array Assembly (generation process)

FLOW IN Main Power Bus Wh 2.40

─────────────────────────────────────────────────────

Archetype Generation (0100) — creation from process

QTC 2 (energy, Wh)

Encoding SF=×1 D=1 N=24 → (24×1)/10 = 2.4 Wh ✓

Bits 33-360 1 0 0 — Generation archetype

Status Settled

Bit 29 = Bit 37 = 1 — cross-layer validation PASS

─────────────────────────────────────────────────────

Example 03 Factory Material Transformation

A press station transforms a 50 kg steel billet into a 48.2 kg stamped part plus 1.8 kg of scrap. Archetype: Transformation (0111). QTC=1 (mass, grams). Two records in a compound group: main part output + scrap output. Conservation: 50,000 g in = 48,200 g part + 1,800 g scrap. Batch balance = 0.

─────────────────────────────────────────────────────

BITLEDGER COMPOUND FLOW RECORD [1 of 2]

Session : FloorNet / Press Station 04 (node 12)

Batch : Shift 3 / Run 047 / Unit: grams (mass)

─────────────────────────────────────────────────────

FLOW OUT Steel Billet Input Store g 50,000

FLOW IN Stamped Part Output Store g 48,200

─────────────────────────────────────────────────────

Archetype Transformation (0111) — form change

Encoding N=48200: A=188 r=8 → (188×256)+8 = 48,200 g

Bit 39 1 = Partial — continuation follows (scrap record)

─────────────────────────────────────────────────────

BITLEDGER COMPOUND FLOW RECORD [2 of 2] — CONTINUATION

─────────────────────────────────────────────────────

FLOW OUT Steel Billet Input Store g 1,800

FLOW IN Scrap Collection Bin g 1,800

─────────────────────────────────────────────────────

Archetype Compound Continuation (1111)

Encoding N=1800: A=7 r=8 → (7×256)+8 = 1,800 g

Bit 39 0 = Full — compound group closed

─────────────────────────────────────────────────────

Balance 50,000 − 48,200 − 1,800 = 0 g — CONSERVATION HOLDS ✓

─────────────────────────────────────────────────────

Example 04 Satellite Power Settlement — 3-Leg Transfer

Satellite A settles a 0.8 kWh power obligation to Satellite B, routing through Satellite C as relay node. Three-leg compound settlement. Archetype for settlement legs: Creditor-to-Debtor (0011). Final leg: Compound Continuation (1111). QTC=2 (energy, Wh). D=2, SF=×1. N=80 → 0.80 Wh per leg.

─────────────────────────────────────────────────────

BITLEDGER COMPOUND FLOW RECORD [1 of 3]

Session : Constellation Ops / Sat-A (node 01)

Batch : Orbit 142 / Event 009 / Unit: watt-hours

─────────────────────────────────────────────────────

FLOW OUT Satellite A Power Reserve Wh 0.80

FLOW IN Satellite C Relay Account Wh 0.80

─────────────────────────────────────────────────────

Archetype Creditor-to-Debtor (0011) — obligation settlement leg 1

Encoding N=80: A=0 r=80 → (0×256)+80 = 80 → /100 = 0.80 Wh

Bit 39 1 = Partial — leg 2 follows

─────────────────────────────────────────────────────

BITLEDGER COMPOUND FLOW RECORD [2 of 3] — CONTINUATION

─────────────────────────────────────────────────────

FLOW OUT Satellite C Relay Account Wh 0.80

FLOW IN Satellite B Power Reserve Wh 0.80

─────────────────────────────────────────────────────

Archetype Compound Continuation (1111) — leg 2

Bit 39 1 = Partial — leg 3 follows

─────────────────────────────────────────────────────

BITLEDGER COMPOUND FLOW RECORD [3 of 3] — CONTINUATION

─────────────────────────────────────────────────────

TYPE Debt closure confirmation record

FLOW OUT Satellite B Open Debt Account Wh 0.80

FLOW IN Satellite B Settled Account Wh 0.80

─────────────────────────────────────────────────────

Archetype Compound Continuation (1111) — group close

Bit 39 0 = Full — compound settlement complete

Balance 0.80 − 0.80 − 0.80 + 0.80 = 0 Wh — CONSERVATION HOLDS ✓

─────────────────────────────────────────────────────

Transmission Resilience · Three Independent Mechanisms

Error Detection

Three independent mechanisms guard every record. At interplanetary distances, cosmic ray bit flips are real threats. Each mechanism catches a different failure mode.

The BitLedger error detection architecture was designed for financial data integrity. In engineering deployments — particularly aerospace, deep space, and remote industrial contexts — the same mechanisms provide resilience against physical transmission hazards that financial systems never encounter.

Session Level

CRC-15

CRC-15 computed over Layer 1 (64 bits total). Detects all burst errors ≤15 bits. All single-bit, double-bit, and odd-count errors in the session header. Protects sender identity, domain declaration, permissions, and session defaults. Cost: 15 bits, computed once per session.

What it catches: Bit flips in sender identity, domain declaration, or session defaults that would cause all subsequent records to be misinterpreted.

Record Level

Cross-Layer Validation

Bit 29 must equal Bit 37. Bit 30 must equal Bit 38. These flag pairs carry the same information in two independent positions. A single-bit flip in either position creates a mismatch that is detected immediately. Cost: zero — uses existing fields.

What it catches: Direction or status flag corruptions that would post a flow in the wrong direction (propellant recorded as arriving at tank instead of leaving it) or with the wrong settlement status.

Batch Level

Conservation Invariant

Any flow record that causes a non-zero batch balance triggers rejection. This catches phantom flows created by corruption, missing records, and duplicated records — failure modes that bit-level CRC cannot see. Cost: 4 bits in Layer 2 (Rounding Balance field).

What it catches: Semantic errors — corruptions that pass byte-level CRC but create physically impossible conservation states.

Deep Space Scenario — Cosmic Ray Bit Flip

At interplanetary distances a single galactic cosmic ray can flip multiple bits in a memory register or transmission buffer. Standard error correction codes at the transport layer (CCSDS, DTN) handle raw bit errors. BitLedger's conservation-invariant validation operates at the semantic layer — it catches errors that byte-level correction misses.

Without BitLedger

Transport layer CRC passes — bit flip undetected at packet level.
Flow record posted with wrong direction.
Propellant recorded as arriving at tank instead of leaving it.
Mass balance error propagates silently into mission planning.
No detection until physical inventory audit — possibly days later.

With BitLedger

Cosmic ray flips bit 29 of a flow record mid-transmission.
Bit 29 ≠ Bit 37 → cross-layer validation FAILS.
Record rejected before posting.
NACK sent. Retransmission requested.
Mass balance preserved. Zero propagation of error.

Comparison to Conventional Telemetry

Capability	Raw Telemetry	BitLedger Engineering Mode
Records individual events	Yes	Yes
Verifies bit integrity	CRC on packet only	CRC-15 on session + cross-layer validation per record
Detects lost records	No — silent data gap	Yes — batch close count mismatch
Enforces conservation	No — application must check	Yes — at wire level, per batch
Detects phantom flows	No	Yes — unpaired flow creates non-zero balance
Handles compound events	Multi-packet, complex parsing	Native compound continuation, single stream
Transmission overhead	Variable, schema-dependent	Fixed 40 bits per flow record

Domain Codes 10 and 11

Hybrid & Custom Domains

Hybrid Domain (bits 3–4 = 10)

When bits 3–4 = 10, both semantic layers are active simultaneously. A single batch can contain records that represent financial obligations alongside physical flow records. This is the appropriate domain for systems where engineering operations create financial consequences — mission operations with contractual billing, industrial processes with commodity trading, or infrastructure with financial settlement.

In hybrid mode, the decoder uses the account pair field (bits 33–36) together with the debit/credit flag (bit 31) as a domain disambiguation signal. Where the financial pair codes and engineering archetype codes overlap, the extension byte carries a 1-bit domain flag to resolve the ambiguity.

Hybrid use case: A Mars supply chain tracks physical mass flows (engineering domain) for mission planning and financial obligations (financial domain) for Earth-side contracts in the same session. One session header. One CRC-15. Both conservation invariants enforced simultaneously — physical mass balance and monetary double-entry balance — on the same batch stream.

Custom Domain (bits 3–4 = 11)

When bits 3–4 = 11, the receiver waits for a Custom Domain Extension Block transmitted immediately after Layer 1 close, before the first Layer 2 batch header. This block redefines the 16 relationship codes and up to 64 quantity type codes for the session.

── CUSTOM DOMAIN EXTENSION BLOCK ──────────────────────

Byte 1 Block length in bytes (1–255)

Bytes 2–3 Domain identifier string prefix (2 ASCII chars)

'SC' = spacecraft 'MF' = manufacturing

'RB' = robotics 'SG' = smart grid

Byte 4 Number of relationship codes declared (1–16)

Bytes 5+ Relationship code declarations

Each: 1-byte code + 2-byte label index

Label index references shared label dictionary

... Quantity type code declarations (same format)

Final byte CRC-8 over the block for integrity

────────────────────────────────────────────────────────

Enhancement Category 1101 (Context Declaration) carries

the extension block as a structured session parameter

update. Control byte format: 0 101 VVVV (type 101,

4-bit payload). Length declared in payload or following

extension byte chain.

────────────────────────────────────────────────────────

Bits 3–4	Domain	Declaration Required?	Decoder Behaviour
`00`	Financial	No	Load financial account pair labels and currency table. Standard Protocol v3.0.
`01`	Engineering	No	Load universal flow archetype labels and physical quantity type table (this document).
`10`	Hybrid	Partial	Load both label sets. Record-level disambiguation via extension byte where ambiguous.
`11`	Custom	Yes	Wait for extension block before processing any batches. CRC-8 validates the block.

Wire Format · Transport Agnosticism

Transport Compatibility

The Universal Domain record is byte-for-byte identical to the Financial domain record. A financial decoder reading an engineering-domain record sees valid wire structure — it reads the SOH bit, validates the CRC-15, processes the batch header, and reads each 40-bit record without error. What changes is which interpretation table the decoder loads after reading bits 3–4.

Domain bits are the interpretation switch: After Layer 1 CRC validates, the decoder reads bits 3–4 and loads the appropriate label table. If bits 3–4 = 00, it loads account pair names and currency codes. If bits 3–4 = 01, it loads flow archetype names and quantity type codes. The 40-bit records that follow are processed identically by the same state machine in both cases.

BitLedger records are transport-agnostic. The 40-bit record is a self-contained payload. It can be carried inside any transport protocol without modification:

Transport	Context	BitLedger Role
CCSDS	Spacecraft telemetry	BitLedger records as CCSDS packet payload. Transport handles routing; BitLedger handles semantic integrity and conservation validation.
DTN / Bundle Protocol	Deep space delay-tolerant networking	BitLedger session survives link interruptions. Layer 1 CRC validates session on reconnect. Conservation invariant holds across disrupted delivery.
MQTT	IoT edge networks	BitLedger records as MQTT message payload. Broker handles delivery; BitLedger handles conservation. Natural fit for sensor network mass/energy accounting.
Raw RF	Point-to-point embedded systems	BitLedger records transmitted directly. No transport overhead. Minimum 5 bytes per flow event. Appropriate for microcontroller-class hardware.
Ethernet / IP	Industrial control, factory floor	BitLedger over UDP or TCP. Batch close control record provides application-layer delivery confirmation independent of transport acknowledgement.

Bandwidth

Fixed cost · 40 bits per flow record · 5 bytes

No schema. No field names. No delimiters. No compression step.

100 flow records · 500 bytes on the wire

vs. ~15,000 bytes CSV · ~80,000 bytes JSON

Deep space link budget · 1 kbps link

100 records / second = 500 bytes/s = 4,000 bps → feasible

Same 100 records in JSON = 80,000 bytes/s = 640 kbps → infeasible

Real-World Applications

Engineering Deployments

Five real-world systems with full configuration detail. In every case the wire format is byte-for-byte identical to the financial specification. Only the semantic layer changes.

System	Primary Quantity	Domain
Spacecraft Propellant Management	Mass (grams) · QTC=1	Engineering	▾
System Description Propellant and pressurant mass tracking across all tanks, feed lines, valves, and thrusters. Every burn event is a flow record. Conservation invariant detects leaks, sensor faults, and unaccounted venting in real time. Archetypes Used Source-to-Sink (0001) for tank-to-thruster burns. Internal Transfer (1011) for tank crossfeed. Accumulation (1100) during resupply docking. External Input (1001) for resupply delivery. State Commit (1101 in financial, equivalent Depletion 1101 in engineering) for inventory snapshots. QTC Selection QTC=1 (mass, grams). SF=×1000 for kg-resolution events. SF=×1 for gram-precision calibration records. D=0 for integer-gram precision. Compound continuation links propellant burn records to thrust-produced records (QTC switch via control byte 0 001 QQQQ). Conservation Invariant Form `mass_tank_out = mass_thruster_in + mass_line_residual` Any non-zero batch balance → leak or sensor fault alert. Batch close count mismatch → telemetry loss during burn sequence. Bandwidth Typical burn event: 3–5 records (burn, residual, tank state). 5 records × 5 bytes = 25 bytes per event. At 1 kbps, 40 burn events per second recordable — adequate for any maneuvering scenario.
ISS ECLSS Life Support Tracking	Mass (atmosphere gases, water) + Energy	Engineering	▾
System Description Environmental Control and Life Support System tracks O₂, CO₂, N₂, and water mass flows across generation, consumption, and recovery subsystems. The most complex conservation system on any crewed spacecraft — any undetected mass imbalance is a crew safety issue. Archetypes Used Generation (0100) for O₂ from electrolysis. Consumption (0101) for crew O₂ use and CO₂ production. Recycling/Recovery (1110) for water recovery from condensate and urine. Loss (mapped to External Output 1010) for CO₂ vented via Sabatier. Source-to-Sink (0001) for distribution to crew modules. QTC Selection Multi-quantity batch (QTC=63). Control byte switches between QTC=1 (mass) and QTC=2 (energy) within the same ECLSS batch. Water measured in QTC=13 (fluid volume, mL) for OGA input. Compound continuation links O₂ generation records to power consumption records. Conservation Invariant Form `O₂ generated + O₂ reserve = O₂ consumed + O₂ vented` `water in = water consumed + water recovered + water stored` Non-zero balance on O₂ or water → automated crew alert. Protocol detects this before any application audit. Bandwidth ECLSS logs approximately 50–100 flow events per hour at steady state. 100 records × 5 bytes = 500 bytes/hr. Negligible bandwidth. Compatible with ISS 1553B internal bus (1 Mbps) or any slow-link backup.
LEO Satellite Power Constellation	Energy (watt-hours) · QTC=2	Engineering	▾
System Description Constellation of LEO satellites sharing power across inter-satellite links (ISL). Nodes with surplus solar generation during illuminated phase lend power to nodes in eclipse. Debts recorded in real time; settled at next illuminated phase. BitLedger handles both the power flow accounting and the obligation ledger in one session stream. Archetypes Used Generation (0100) for solar output. Consumption (0101) for payload power draw. Debtor-to-Creditor (0010) when a satellite draws from the constellation pool. Creditor-to-Debtor (0011) to settle. Source-to-Sink (0001) for ISL power routing. Reservation (mapped to Accumulation 1100) for eclipse reserve allocation. QTC Selection QTC=2 (energy, Wh). SF=×1, D=2 for 0.01 Wh precision. A single node ID maps to each satellite. Sub-Entity ID maps to specific power system modules (battery bank, solar array, payload bus). Cross-satellite debts: sender = creditor satellite node ID, receiver = debtor node ID. Conservation Invariant Form `energy_generated + energy_drawn = energy_consumed + energy_stored + energy_lent` Batch balance = 0 confirms constellation is energy-neutral for the accounting period. Non-zero balance → unrecorded draw or sensor fault. Bandwidth Constellation of 12 satellites: ~20 power events per orbit × 12 nodes = 240 records per orbit (90 min). 240 × 5 bytes = 1,200 bytes per orbit. At ISL data rate (1+ Mbps), negligible. Compatible with store-and-forward over DTN if ISL is unavailable.
Factory Floor Mass Balance	Mass (materials) + Service-Hours · QTC=1,14	Hybrid	▾
System Description Work-in-process tracking across factory stations. Each station is a node. Material flows between stations as Source-to-Sink; transformation at each station records mass input vs. finished output + scrap. Hybrid domain simultaneously records financial obligations (supplier contracts) alongside physical mass flows. Archetypes Used Source-to-Sink (0001) for station-to-station material transfer. Transformation (0111) for in-station processing with scrap. External Input (1001) for raw material delivery from supplier. External Output (1010) for finished goods shipment to customer. Debtor-to-Creditor (0010) for supplier payment obligations (financial domain in hybrid session). QTC Selection QTC=1 (mass, grams) for material tracking. QTC=14 (service obligation, minutes) for machine time accounting. Hybrid domain enables simultaneous financial records (currency index = USD) for supplier payment events in the same session. Control byte switches QTC within multi-quantity batches. Conservation Invariant Form `raw_material_in = finished_parts_out + scrap_out + in-process_inventory` Scrap must be explicitly recorded. Any material that leaves a station without an accounting record creates a non-zero balance. Protocol detects yield losses that manual audits miss for days. Bandwidth High-throughput factory: 1,000 part-movements per shift. 1,000 records × 5 bytes = 5,000 bytes per shift = 83 bytes/minute. Trivial over any factory network (Ethernet, MQTT, or OPC-UA). Each record is self-describing — no schema lookup required at receiving workstation.
Smart Building Energy Management	Energy (kWh) · QTC=2	Engineering	▾
System Description Building energy accounting across generation (solar roof, CHP plant), storage (battery bank, thermal store), consumption (HVAC, lighting, IT, EV charging), and grid import/export. Every flow tracked in real time. Conservation invariant confirms that all energy is accounted for — no phantom consumption, no unrecorded export. Archetypes Used Generation (0100) for solar and CHP. Accumulation (1100) for battery charging. Depletion (1101) for battery discharge. Source-to-Sink (0001) for distribution bus to loads. External Input (1001) for grid import. External Output (1010) for grid export (feed-in). Loss/Dissipation mapped to Consumption (0101) for thermal losses. QTC Selection QTC=2 (energy, Wh). D=2 for 0.01 Wh precision on metered flows. SF=×1 for sub-kWh granularity. Each building zone is a node. Sub-Entity ID maps to specific meters or circuits. Grid import/export node IDs declared in Layer 1 as external-boundary nodes. Conservation Invariant Form `solar + CHP + grid_import = HVAC + lighting + IT + EV + battery_net + grid_export + losses` Batch period = 15 minutes (standard metering interval). Non-zero balance → unmetered load or meter fault. Alert triggers before billing cycle closes. Bandwidth 50-node building: ~200 flow events per 15-min batch. 200 records × 5 bytes = 1,000 bytes per batch = 67 bytes/minute. Fits easily over building BACnet or MQTT infrastructure. No cloud upload required for real-time conservation checking — all validation done at edge by local decoder.

Any ConservedScalar

Domain Declaration

Domain Code Table

16 Universal Flow Archetypes

Description

Activation Condition

Record Bits 33–36

Description

Activation Condition

Examples

Record Bits 33–36

Description

Activation Condition

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Examples

Record Bits 33–36

Description

Activation Condition

Examples

Record Bits 33–36

Quantity Type Codes

Scaling Examples

The Conservation Invariant

Enforcement Mechanisms

Worked Mass-Balance Batch — Pseudocode

Scenario · Spacecraft propellant transfer and burn · 3 records

Conservation Tolerance in Physical Systems

Worked Examples

Error Detection

Deep Space Scenario — Cosmic Ray Bit Flip

Without BitLedger

With BitLedger

Comparison to Conventional Telemetry

Hybrid & Custom Domains

Hybrid Domain (bits 3–4 = 10)

Custom Domain (bits 3–4 = 11)

Transport Compatibility

Bandwidth

Engineering Deployments

System Description

Archetypes Used

QTC Selection

Conservation Invariant Form

Bandwidth

System Description

Any Conserved
Scalar