jonnify·bcs /bcs/bus/jobs-are-entities/the-orders-dividend

B3.2 · dive 3 — the order theorem's dividend

One set is three indexes.

Because job ids are branded snowflakes, the pending structure gets Chapter 1.2's theorem for free on a new substrate: the ids are the chronology. The set is "simultaneously the FIFO (lex-min is the oldest job) and the browse index (lex-max-down is newest-first) and the time-range index (an id-prefix range is a time window)". J4 collects the dividend on stage; J5 closes the loop on the cargo law.

Source: content/bcs3.2.md, quoting bcs_rung_3_2_check.out. On stage the set holds 301 pending; the model below holds six.

The three indexes, performed. Six JOB ids minted in sequence for this model with the course's minting tool — demonstration data, not committed evidence; the committed figures sit in the frozen record below. Every answer is computed live from the bytes.
JOB0Nvmd8aV5iy minted 1st lex-min JOB0Nvmd8gSfSK minted 2nd JOB0Nvmd8mzRRo minted 3rd JOB0Nvmd8tnoZM minted 4th JOB0Nvmd90tmoy minted 5th JOB0Nvmd96ZlQG minted 6th lex-max
readout · Ask the set an index question. One sorted set, every member at score zero — the FIFO, the browse index, and the time-range index are the same bytes read three ways.

Static record — the FIFO head is JOB0Nvmd8aV5iy, the first id minted; newest-first browse returns the last five in reverse mint order, JOB0Nvmd96ZlQG first; the prefix JOB0Nvmd9 cuts the window that holds the last two mints. No timestamp column anywhere.

§1

The transcript

bcs_rung_3_2_check.out · verbatim · this dive reads J4 and J5
content/echo_data/runtimes/elixir/bcs_rung_3_2_check.out · verbatimfrozen
boot: the registry grows by one -- JOB, work as a kind with identity and lifecycle
J1 surface ok -- the bus module's surface: enqueue, browse, pending_size -- scripts and key shapes are nobody's business
J2 idempotent ok -- enqueue is one script and idempotent by id: first call enqueued, second answered duplicate, the row untouched and pending holds 1
J3 kind ok -- kind policy lives in the script: an ORD id in the job position answers EMQKIND on the wire -- the key let it pass, the law did not
J4 dividend ok -- the order theorem's dividend: newest-first browse over the ids themselves returns the last five minted in reverse mint order; the very first job sits at the head; 301 pending, no second index anywhere
J5 cargo ok -- the cargo law holds: the payload carries ORD0Nt6z93U3dY and a quantity, never a row -- decoded and re-parsed on the far side of the wire
PASS 5/5
§2

The dividend

content/bcs3.2.md · What · Who

J4 collects on stage what the structure promised: newest-first browse over the ids themselves returns the last five minted in reverse mint order; the very first job sits at the head; 301 pending, no second index anywhere. The rung holds three hundred and one pending jobs and asks the set the operator's questions — newest-first, oldest-first — and the answers fall out of the bytes, because equal scores order lexicographically and for branded ids byte order is mint order.

For producers: retry-safe enqueue by construction — fire it again on any doubt, the id is the receipt. For operators: browse pending newest-first with one command and cut time windows as lex ranges over id prefixes, "no schema migration ever having happened because the grammar is the schema and keys appear on first use." Two honest boundaries travel with the dividend: browse covers pending only — terminal-state browsing arrives with the states themselves — and multi-producer ordering is arrival-interleaved, as any queue's is; within one producer, mint order holds. And B3.3 · The State Machine in Lua inherits a pending set whose lex-min is always the claimable head.

§3

The cargo law

content/bcs3.2.md · What · When

J5 closes the loop: the payload carries ORD0Nt6z93U3dY and a quantity, never a row -- decoded and re-parsed on the far side of the wire. The payload decodes on the far side to a map carrying ORD0Nt6z93U3dY and a quantity, the id re-parses through the contract, and no row ever crossed the wire.

The chapter's When states the rule for callers: "Put ids and parameters in the payload; never rows, and never blobs — a large artifact gets stored where artifacts live and referenced by its name, like everything else in this series."

The cargo, inspected. The committed id from the record, run through the contract's own arithmetic — the same pure decoder the footer stamp runs. The quantity stays off stage: the record commits the field, not the number.
readout · Inspect the cargo. Two names and the law: the payload carries an id and a quantity, and the far side re-parses the id through the same contract that minted it.

Static verdicts — decoded: order_id → ORD0Nt6z93U3dY · qty → a quantity (the field on the record, the number off stage) · re-parsed through the contract: namespace ORD, node 7, seq 0, minted 2026-06-11 09:01:41 UTC · the row never ships — ids and parameters only.

§4

References

sources · related

Sources

  • Valkey — ZRANGEthe REV and BYLEX forms behind newest-first browse; equal-score elements order lexicographically
  • Valkey — Sorted setsthe same-score lexicographic family as a generic index; the different-scores caveat behind the score-zero decision

Related