jonnify·bcs /bcs/ideas/time-inside-the-name

B1.5 · The Time Inside the Name — manuscript chapter 1.5

Whose clock is authoritative?

Every chapter so far has leaned on chronology without taking it as a subject. The order theorem turned keys into timelines, the storage chapter ranged stream windows by id arithmetic, the substrate paged newest-first with no clock in the process — time has been load-bearing on every page and examined on none. This module examines it: what the 41 bits promise, what they refuse to promise, the discipline the minter owes its clock, and the law that keeps the trading system from confusing the kinds of time it lives with.

The chapter is content/bcs1.5.md. The contract owns the bits; this module states the policy.

The three clocks. Select a clock to read which questions it answers and where its value lives.
identity time the id’s — read through unix_ms when this architecture first named it event time someone else’s clock — data carried as a property, never in the id the store’s clock a TTL — the row’s rented tenure enforced by the engine at expiry
readout · Select a clock. Static reading: identity time is the id’s — when this architecture first named the entity, readable forever through unix_ms; event time is data — someone else’s clock, carried as a property; a TTL is the store’s time — the name’s time is forever, the row’s tenure is rented.
§1

Two times that look alike

content/bcs1.5.md · Why

A trading platform runs on two times that look alike and are not. There is the moment an exchange says a fill happened — event time, owned by someone else’s clock, carried as data, disputed in arbitration. And there is the moment this architecture first named the fill — identity time, owned by the minter, carried inside the id, readable forever through unix_ms.

Conflating them is the subtle cousin of the second clock from Chapter 1.2: not a duplicate timestamp beside the id, but the id’s timestamp doing a job it never promised to do. Part VIII cannot be written until the line is drawn, and the line is an idea — which makes it Part I’s job.

§2

The free creation instant

content/vectors.json · decode + unix_ms

Identity time is a free creation instant: the canonical pair in the normative vectors decodes USR0NgWEfAEJfs to 320636799581945856 and reads unix_ms as 1780512970164 — no column required.

content/vectors.json · the canonical decode pairfrozen
id         USR0NgWEfAEJfs
snowflake  320636799581945856
unix_ms    1780512970164 -- read from the id; no column required

The litmus for everything in this module is one question — whose clock is authoritative for this claim? — and the moment the answer is “not ours,” the value is data beside the id, never arithmetic on it.

§3

The dives

three lessons, fixed by the chapter spec
B1.5.1

The 41-Bit Horizon

41 bits of milliseconds above the 2024-01-01 epoch is about 69.7 years; the field exhausts in September 2093 — recorded here, with the successor epoch a planned amendment, never an incident.

dive 1built B1.5.2

The Law of Two Clocks

Identity time vs event time; Lamport’s fifty-year-old foundation; min_for cursors as identity-time arithmetic; event time riding as data beside the name.

dive 2built B1.5.3

The Floor and the Third Clock

The monotonic mint floor as policy of record; a TTL as the store’s clock, priced on the measured table — two mechanisms, deliberately unmerged.

dive 3built

Reach for identity time when the question is about this architecture’s own history — pagination, replay windows, retention cutoffs, first-seen audit, dedupe-by-recency. Reach for event time when the question belongs to another clock’s jurisdiction — matching semantics, regulatory timestamps, PnL bucketing, anything an exchange or a client could dispute.

§4

References

sources · related

Sources

Related