Public provenance register · the receipt chain
السجل
as-Sijill — the register
A sijill is the bound register of an Ottoman or Islamic court: entries written in sequence, each dated, none removable without disturbing the volume. Its authority came from its form. A claim was provable because the register held it, in order, where anyone entitled to look could find it.
This is that instrument in its arithmetic form. Every entry is hashed, and every hash is folded into the one before it, so the register’s final value depends on all of it. The binding is the mathematics. It is provenance infrastructure, not a metaphor.
Current head
11381c38733a3fbf9f437f01db527f96028454263abba59612da44925c3a74f7
- Entries sealed
- 20
- Feed read at
- 2026-08-04 04:47Z
Read live from the published feed. This page holds no stored head — a pinned hash would read as current long after the register had moved on.
the entry
What the register holds
One entry per verified build phase, carrying only the fields already published on the audit log: the phase, its completion stamp, whether its gate passed, and the build hash. No new disclosure is made here. The register adds ordering and arithmetic to records that were already public.
Order is fixed by the data, not by us: entries sort by stamp, then phase, then leaf hash. That ordering is total, so the same set of entries always produces the same head on any machine.
The individual entries are rendered at the public audit log.
the seal
Constants of this register
- Genesis tag
- STEADYWRK-RECEIPTS-GENESIS-v1
- Genesis chain value
- 0d49369e97cfcf77c14fef3c6175663ad473d286cd423b131f83d0f5d3bf190b
- Leaf rule
- receipt_hash = SHA256(canonical_json(receipt)) — canonical_json sorts object keys, no whitespace (equivalently: jq -cS)
- Link rule
- chain_n = SHA256(chain_{n-1} | n | ts | receipt_hash), with chain_0 = SHA256(genesis_tag) and ts = receipt.completed (empty string when null)
- Order
- links are sorted by (ts, phase, receipt_hash) ascending — a total, machine-independent order, so the same receipt set always yields the same head
- Implementation
- packages/ledger (genesisChain, computeChain) — the same chain functions the foresight seal ledger uses
the limit
What it attests — and what it does not
The head is a pure function of the receipt content published here. Changing any character of any receipt changes the head. You can derive the head yourself from this JSON with curl, jq and sha256sum — no trust in this server or its verdict.
Not attested
That history was never rewritten. A chain served alongside the data it commits to shows internal consistency at this moment; it becomes tamper-evident against us only once you have recorded a head and re-check it later. It is not a signature and there is no third-party audit.
No signing key is seated, and none is faked. A detached signature is the next instrument this register needs, and until it exists the register says so on its own face rather than implying a strength it does not have.
the procedure
Recompute the head yourself
The verifier is a single file with no dependencies. It takes no credentials and asks nothing of us beyond the public feed. Read it before you run it — it is short on purpose, so that reading it is cheaper than trusting it.
- Read the published feed. It carries the genesis tag, every entry, each entry’s leaf hash, and the chain value at every step.
- Recompute each leaf: SHA-256 over the entry serialised as canonical JSON — object keys sorted at every depth, no whitespace.
- Recompute the chain: start from SHA-256 of the genesis tag, then fold each entry in position order into the running value.
- Compare your final value to the published head. If they match, the head is a pure function of the data you were shown.
- Record the head and the count it covered. Re-run later: if that head still appears in the chain, those entries are byte-for-byte unchanged.
node scripts/verify-sijill.mjsSource: scripts/verify-sijill.mjs. Pass a URL or a saved copy of the feed as the single argument to check something other than production. Any POSIX or Windows machine with Node and no network privileges beyond an outbound fetch will do.
Exit codes
- 0
- Verified — the head reproduced exactly from published data.
- 1
- Failed — the published head does not reproduce. That is a finding.
- 2
- Unreachable — the feed could not be loaded. A transport failure, never reported as a broken chain.
The three states are kept distinct on purpose. “I could not reach the feed” must never be reported as “the chain is broken”, or the register would manufacture alarm out of a dropped connection.
over time
Checking us later
Record the head you got, and the count k it was computed over. Re-run later: if the recorded head still appears as links[k].chain, the first k links are byte-for-byte unchanged. If it does not appear anywhere in links[*].chain, something before position k moved — either a receipt was back-dated into the middle (which legitimately re-derives every link after it) or a past receipt was altered. The chain makes the disturbance visible; it does not tell you which of the two it was.
The feed
No authentication. No rate-limited key. The endpoint also carries a shell transcript for readers who would rather use curl, jq and sha256sum than run our file.
السجل — بالعربية