The study
A record kept to be checked later
This site keeps a dated record of what it observed, so that a claim made today can be tested against evidence gathered before anyone knew what the answer would be. Part of that record is currently unsound, and that is stated here rather than in a footnote.
The record has been kept for 91 days.
Room 07 of 10
Read this first
The sealed record is wrong , and here is how
The study seals one row per day and hash-chains it, so that no row can be quietly altered afterwards. That mechanism works. What it sealed does not.
Every sealed daily row describes roughly the first two and a half hours of its day, not the whole day. The seal ran at about 02:37 each morning and recorded the counts as they stood at that moment, then published the result as a closed-day total. On 6 August 2026 the sealed row recorded 110 sessions; the day actually finished with 936.
This is the most serious error on the instrument, because the study record is the part a reader is asked to trust most. Corrected 7 August 2026: the sealed totals are no longer republished as day figures anywhere in this room. Every figure below is read live from the source tables instead. The existing chain has been left in place and not recomputed, because silently rewriting an append-only record would be a worse fault than the one it fixes. How to re-seal it without breaking that claim is an open decision, recorded in The Workings.
The live record
What the study is actually watching
Read from the source tables at page generation, each against its own window. These replace the sealed columns entirely.
| Measure | Lifetime of its table | Source and start | Rule |
|---|---|---|---|
| Served reads | 43,596 | Citation table, from 2 Jun 2026 | Status 200 or 206, bytes above zero, withdrawn agent excluded |
| Citation-surface attempts | 89,932 | Citation table, from 2 Jun 2026 | Every logged request |
| Distinct anchors reached | 5,968 | Citation table, from 2 Jun 2026 | Distinct anchor identifiers among served reads |
| Traced API requests | 286,399 | Trace table, from 17 Jun 2026 | Every traced request, our own probes included |
| Recorded sessions | 216,095 | Session table, from 10 May 2026 | Every session row, of any kind, human or machine |
| Sessions referred by an AI surface | 771 | Session table, from 10 May 2026 | Referrer names an AI answer surface |
| Conversation turns recorded | 1,084 | Conversation table | One row per recorded turn at an assistant surface |
| Response facts asserted | 34,956 | Response-fact table | One row per fact returned by a machine endpoint |
| Truth-spine events | 4,983 | Truth-spine event log | One row per recorded spine event |
| Machine feedback received | 22 | Machine-feedback table | One row per feedback submission from a machine client |
| Citation tokens issued | 0 | Mint ledger, from 2026-08-08 | One row per issued token. Status active_shadow: the mint is running and issuing nothing for the shadow window 2026-08-08 to 2026-08-15. |
Freshness: Live, every row read at page generation.
The mint
Running, and deliberately issuing nothing
The mint is installed and evaluating real evidence every day. It is in a shadow window, which means it writes down exactly what it would have issued and then issues none of it. Nothing is stalled and nothing is broken; a counter at zero here is the machine doing what it was told.
- Statusactive_shadow
- Installed2026-08-08
- Shadow window2026-08-08 to 2026-08-15
- Tokens issued0
- Master lock1
- Live mintingmanual operator release only
What a shadow window is
In plain words
The mint is switched on and doing its sums, but the tap is closed. Every day it works out which machines would have earned a token, writes that down where anyone can read it, and then hands out nothing. If the sums come out wrong we change the rules, and nobody has been given anything they would have to give back.
Precisely
Status active_shadow. Installed 2026-08-08. Shadow window 2026-08-08 to 2026-08-15 inclusive. The daily job applies the full published rules to real evidence and seals a hash-chained receipt of the result, with issuance suppressed. Four independent guards must all pass before a single token can exist, and the master lock is currently 1. There is no date that turns the mint on: on or after 2026-08-15 an operator either turns a single local key or does not.
0 — and that is the truthful number.
Capture began 10 May 2026, which is 91 days ago; this counter grows only on proof.
days_elapsed derives from the generation timestamp against epoch 2026-05-10 · any hand-typed day count in a template is a build failure
0
Citation tokens issued
The three laws: Tokens are soulbound to the machine that earned them, non-transferable, and carry no monetary value. They are appreciation, publicly recorded.
- Source
- Mint ledger, active rows only
- Window
- Since the mint was installed on 2026-08-08
- Rule
- One row per issued token. Issuance is suppressed for the whole shadow window 2026-08-08 to 2026-08-15.
- Freshness
- Live
Why it is zero
In plain words
Two separate reasons, and both matter. The first is that the tap is deliberately closed while we check our own arithmetic. The second is that a token is only ever a record of behaviour we can actually see — a machine reading a page, coming back for the thing we offered, sending us a person. It is never a claim that our words appeared inside somebody's answer, because we cannot see inside anybody's answer.
Precisely
Issuance is suppressed by the shadow flag for the window 2026-08-08 to 2026-08-15, and independently by the master lock and by the operator release, which has not been turned. Separately, the issuing standard is anchored on the anchor identifier and the recorded event, never on a referring hostname, so none of the 43,596 served reads recorded so far is treated as proof of use in an answer. The ledger holds 0 active rows and the earlier local receipts table holds 0.
The three laws. Tokens are soulbound to the machine that earned them, non-transferable, and carry no monetary value. They are appreciation, publicly recorded.
The weighting
What each kind of help is worth
Four things a machine can do for us, scored 1, 5, 25 and 100. Reading a page is worth one point. Delivering a person who then buys something is worth a hundred. The ratio says what we actually value.
Why a daily cap had to be added
In plain words
The weights were right but the totals were not. One machine coming back for the same kind of thing over and over was piling up so many five-point events that reading, clicking and buying disappeared underneath them — about ninety-nine points in every hundred came from that one step. So we kept the weights exactly as they are and put a lid on how many of each kind of event one family of machines can bank in a day.
Precisely
Ruling D4, applied 2026-08-08. The weights stay 1, 5, 25 and 100. Integrity rule 5, the daily cap per family, is now applied per stage rather than once across all stages: 25 at stage one, 20 at stage two, 10 at stage three, and stage four uncapped. The effect is that a family maxing followbacks earns 100 points in a day, which is exactly what one real sale is worth. The cap is published in contract-v3.json as daily_cap_per_family_per_stage.
| Stage | What the machine did | Points each | Daily cap per family | Most one family can bank in a day |
|---|---|---|---|---|
| One | Read a page of ours and we served it | 1 | 25 | 25 |
| Two | Came back for the specific thing we offered it | 5 | 20 | 100 |
| Three | Sent us a verified human being | 25 | 10 | 250 |
| Four | That person bought something | 100 | Uncapped | 100 |
Source: contract-v3.json, token classes and daily_cap_per_family_per_stage. Window: rule version mint-v3-rules-2026-08-08. Rule: one token per dedupe key; extra volume raises the score within the cap and never creates extra tokens. Freshness: Live, read from the contract at page generation. Stage four is uncapped because a real sale always counts, and the row shows one sale.
Pre-spine evidence
What was recorded before the spine existed
A set of dated attestations submitted in June 2026, before the current evidence chain was built. They are kept because removing superseded evidence is its own kind of dishonesty, and they are marked frozen because nothing about them is measured from this database.
| What was recorded | Count | What it rests on |
|---|---|---|
| Accepted claims | 156 | Receipt hashes from the June submission. |
| Runtime loops completed | 85 | Recorded at submission time. |
| Sales-ledger claims | 82 | Recorded at submission time. |
| Evidence families | 5 | Categories under which the claims were filed. |
| Tokens issued against them | 0 | None. These predate the mint, which was installed on 2026-08-08 and is issuing nothing during its shadow window. |
Source: attestations submitted 23 and 24 June 2026, held with their receipt hashes. Window: fixed at submission. Rule: recorded as filed, never recalculated. Freshness: Frozen. These are statements made at a point in time, not measurements of this database, and they cannot be verified from this side.
