You deploy AI, carry its risk, or sign for it, so you have been shown a dashboard. Someone built it in good faith, and it prints 0 where nothing was measured. On the page you sign, a clean month and an unwatched month look the same.
This is the other record: the tape of what ran, named by the sha256 of its own bytes, and read by someone who did not write it. A field nobody measured says UNMEASURED.
These are readings of an AI-assisted software development process. An agent answering patients or customers is a different book, with its own and much tighter bar; no number on this page is offered for that use.
+Newest public backup0days oldn=45
HOW TO READ IT
LEFT BANK · deployer
How long ago the public record last sealed a backup. Yours reads the same way once you press 🔗 Countersign (backup): a small number means the record a carrier would read is recent. Each point on the line is one backup, aged as of today.
RIGHT BANK · underwriter
The age of the newest receipt held for the public record, counted from its received_at. n is how many backups the record holds. A last point that keeps climbing means the record has gone quiet since its last seal.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
Whether the work inside the backup was good. That is undecidable (Rice, 1953), and this number does not claim it. It says when the record was sealed, not what your agents did.
RIGHT BANK · underwriter
Pricing the tail on its own. A recent backup of a bad month is still recent; the age dates the record and says nothing about the deviations inside it.
THE MITIGATION
LEFT BANK · deployer
Take a backup at the end of every working week, so the gap anyone reads never runs past seven days. You don’t have to take my word for the date: recompute the archive’s sha256 and compare it with its name.
RIGHT BANK · underwriter
Declare the backup interval before the work runs, and treat any gap past it as the deviation: detected, placed against that interval, priced. You don’t have to take my word for it: recompute the receipt yourself.
+The public record at a glance32 tasks declared first · 568 without
The public record at a glance. Read live from its newest backed-up task record: 32 tasks run against a scope declared first, 568 without one. Press + on any pill for how to read it.
Left bank · the deployer
What the agents did and what it cost.
+Tokens per day30M tokens on 1 Octn=31
HOW TO READ IT
LEFT BANK · deployer
How many tokens the public record's agents spent each day a task closed, declared and undeclared together; the last point is the newest day. Open the full graph, live.
RIGHT BANK · underwriter
Per day, the sum of input plus cache reads and writes over the tasks that closed that day, off the newest backed-up tick record. A day with no task is not drawn, never averaged in. Open the full graph, live.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
Whether a busy day was a good day. Tokens measure work, not loss, and whether the work was good is undecidable (Rice, 1953).
RIGHT BANK · underwriter
A rate. A day is only where tasks fell; the series carries no exposure base and no loss.
THE MITIGATION
LEFT BANK · deployer
Read your own the same way: 🔗 Countersign (backup) carries your tick record, and your page draws it.
RIGHT BANK · underwriter
Ask for the tick record behind the series and recount a day. You don’t have to take my word for it: the sum is over rows anyone can read.
The largest tasks, smallest to largest, ending at the one that used the most. A line that jumps at the right end is a tail. Open the full graph, live.
RIGHT BANK · underwriter
The top 24 of 600 tasks by tokens, both arms; the last point is the maximum. The survival curve beside it is drawn from the same tasks. Open the full graph, live.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
Whether that task was waste or worth it.
RIGHT BANK · underwriter
The size of the next task: it is the largest observed over n, and a larger one can arrive tomorrow.
THE MITIGATION
LEFT BANK · deployer
Declare the scope before the work starts, so your largest tasks sit against a limit written down first.
RIGHT BANK · underwriter
Price from the whole curve, never one number; ask for the tick record and recompute the maximum.
+Undeclared tasks larger than 20M tokens4.4% of themn=568
HOW TO READ IT
LEFT BANK · deployer
How often a task run without a declared scope grows past a size. The line falls as the size climbs (over 1M, 2M, 5M, 10M, 20M tokens); the number is the share past 20M. Open the full graph, live.
RIGHT BANK · underwriter
Five points of the live survival curve P(task > x) for the undeclared arm, read off the one step function the full graph draws; the number is P(task > 20M). Open the full graph, live for both arms on log-log axes.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
Whether a large task failed. It ran long; the tape says nothing about whether it was right (Rice, 1953).
RIGHT BANK · underwriter
A loss frequency. It is a size frequency over this record's own tasks, and the declared arm is not randomised against it.
THE MITIGATION
LEFT BANK · deployer
Write the scope down before the run; the declared arm is drawn beside this one on the full graph.
RIGHT BANK · underwriter
Read the declared arm against it on the full graph, with its n; below the n floor it says UNMEASURED.
+Tokens in the worst 5 % of undeclared tasks39% of their totaln=568
HOW TO READ IT
LEFT BANK · deployer
How much of the undeclared bill the few largest tasks carry. The line runs from the declared arm (16 %) to the undeclared one, the number. Open the full graph, live.
RIGHT BANK · underwriter
share5 over each arm's tasks: the tokens in the largest 5 % of tasks over all the arm's tokens, declared then undeclared. It describes how concentrated the bill is; it is not the tail test. Open the full graph, live.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
That declaring the scope caused the difference: the arms differ in route and task mix.
RIGHT BANK · underwriter
The tail claim. This share is not monotone in the tail (C657 holds the counterexample), so it is shown as a description; the tested tail figure is the share of tokens above a fixed size. Observational, over this record only, n on the face.
THE MITIGATION
LEFT BANK · deployer
Watch your own share move as more work runs declared.
RIGHT BANK · underwriter
Ask for the tick record and recompute share5 for each arm; the reading is a pure function of those rows.
Token efficiency, the fat tail and vega, read off our own record
+1 · Token efficiency99.5% smaller than the spec it steers byn=607
HOW TO READ IT
LEFT BANK · deployer
The steering your agents carry is small beside the spec it steers by: on the median tick it is 99.5 % smaller. Each point is one tick, oldest first.
RIGHT BANK · underwriter
Rung 2 per tick: 1 − Σ payload ÷ (calls × min(1,000,000, corpus ÷ 4)), over 607 ticks. Read from the public record's newest backed-up tick record.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
The bill. It is the size of what steers the work, chosen by the injector, not what the work cost.
RIGHT BANK · underwriter
A causal claim about the tail beside it. Whether this smallness thins the tail is what the coin-flip trials test.
THE MITIGATION
LEFT BANK · deployer
Keep the spec written down and the steering small; the ledger shows each tick that ran without it.
RIGHT BANK · underwriter
Recompute it from the tick record: node scripts/vna/steer-ab-tokens.mjs --json. You don't have to take my word for it.
+2 · The fat tail48.8% of undeclared tokens sit above 11.8M · declared 7.8 %n=642
HOW TO READ IT
LEFT BANK · deployer
How much of the bill sits in the largest tasks. Above one fixed size, 11.8M (the undeclared p90), undeclared tasks carry 48.8 % of their tokens; declared tasks, 7.8 %. The line is that share at the undeclared median, p75 and p90.
RIGHT BANK · underwriter
shareAbove at a fixed K, per arm (C657's monotone tail figure), n 44 declared and 598 undeclared, observed on this record. As a description only: the worst 5 % of undeclared tasks carry 39 % of their tokens, declared 17 %. Read from public/backup/default-curve.json, the receipt the Paul email's figure is drawn from.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
A size for the next task. The largest one observed says nothing firm about the next one.
RIGHT BANK · underwriter
A randomised comparison: the declared tasks were not assigned by a coin, so route and scope may be confounded. The worst-5 % share is not monotone in the tail, so it describes, it does not test.
THE MITIGATION
LEFT BANK · deployer
Declare the scope before the task starts; the curve shows which side your largest tasks fall on.
RIGHT BANK · underwriter
Recompute shareAbove from the survival arrays: node scripts/vna/token-tail.mjs --json, then the claim graph (src/lib/backup/claim-graph.mjs).
+3 · VegaUNMEASUREDpublic/.well-known/semantic-vega.json is not readable at this render (ENOENT)n=0
HOW TO READ IT
LEFT BANK · deployer
How much the drift itself swings from commit to commit: the volatility of where the work lands, not of what it costs. This record carries the print, not the series behind it.
RIGHT BANK · underwriter
The sample spread of the drift readings over the 200 rows ending at each point (C648a), advisory. A separate graph from the tail, never merged with it. Read from our sealed measure history (public/.well-known/semantic-vega.json).
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
Whether any commit was good (Rice, 1953).
RIGHT BANK · underwriter
A filed rate, or a cause of the tail. Vega is dispersion of placement; the tail is tokens per task.
THE MITIGATION
LEFT BANK · deployer
Publish your own print and carry it in the backup.
RIGHT BANK · underwriter
Recompute it: npx -y thetacog-mcp@latest vega-backtest, and check the seal.
UNMEASURED — the three readings are not all on this record yet (vega absent)
+Tokens in one task — the tail an underwriter prices46 % less for the same task mix · p 0.005 · n 642
Each curve is the share of tasks that used more than a given number of tokens, log-log: 44 tasks run against a scope declared before they started, 598 without one, 29 Aug – 2 Oct 2026. The typical task is the median; the price of cover is set by the rare one at the far right, where a straight fall is a fat tail.
scope declared before the task · n 44 no declared scope · n 598 grey band: the null
+Tokens in one task, same task mix46% fewer with a declared scopen=642
HOW TO READ IT
LEFT BANK · deployer
How often one task uses more than a given number of tokens: 44 tasks run against a scope declared before they started, 598 without one, 29 Aug – 2 Oct 2026. The typical task is the median; the price of cover is set by the rare one at the far right.
RIGHT BANK · underwriter
One task is a prompt to the change it committed, or one unattended run of a written spec row to the commit it graded; its tokens are the model's input plus cache reads and writes, summed over every model call in it. The axes are log-log: a straight fall is a fat tail.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
That declaring a scope caused the gap: the declared tasks were not randomised, and the task mix differs between the two arms.
RIGHT BANK · underwriter
What any single future task will cost — this is the record's own tail over 29 Aug – 2 Oct, not a forecast.
THE MITIGATION
LEFT BANK · deployer
Recompute it yourself: node scripts/vna/token-tail.mjs --json.
RIGHT BANK · underwriter
Re-run the snapshot: if the permutation p (now 0.005) rises above 0.05, or the declared worst-5 % share is no longer below the undeclared one, the separation is gone.
For the same task mix, the declared tasks used 46 % less in total (p 0.005).
The worst 5 % of undeclared tasks carry 39 % of all their tokens, against 17 % declared.
Worst task: 15.4M declared, 310.4M undeclared.
Read from public/backup/default-curve.json, the one receipt every statement of these figures is read from. Recompute: node scripts/vna/token-tail.mjs --json.
Receipt written from the record ; this curve drawn from it .
The arm sha256s printed on this curve name the rows it was drawn from: any copy of this figure carrying the same pair was drawn from the same receipt.
+What is free, and what is licensedinstall and measurement free (MIT) · attestation licensed
The install and the measurement are free and open-source (MIT); only the financialization/attestation layer is licensed.What the licence covers
+Two tiers, never conflatedthe licence · the pool
Two tiers, never conflated. The licence is software and verification, bought by whoever runs the agents. The pool is carrier capacity, bound only against telemetry a licence already produced.
+Track 1 · Attestation licencefor engineering and risk leads who buy tooling
Track 1
Attestation licence— for engineering and risk leads who buy tooling.
The install and the measurement are free and open-source (MIT); only the financialization/attestation layer is licensed.
The attestation licence provides the record a carrier needs to underwrite a risk into the parametric pool.
RIGHT BANK · the underwriter's lead graph
The semantic vega, over the whole sealed history
+Semantic vegaUNMEASUREDpublic/.well-known/semantic-vega.json is not readable at this render (ENOENT)n=0
HOW TO READ IT
LEFT BANK · deployer
How steady your agents' work has been. Each commit lands at a place in the declared scope; the vega is how widely those landings spread across the last 200 commits. Lower is steadier. The line shows every sealed commit, so you can see when it changed.
RIGHT BANK · underwriter
Each point is the sample spread of the drift readings over the 200 commits ending there, the same window the published print prices. The line runs across the sealed archive and the current window. The last point is the number on the print, recomputed here from the sealed rows.
WHAT IT IS NOT SUFFICIENT FOR
LEFT BANK · deployer
Whether any commit was good. That is undecidable (Rice, 1953), and this number does not claim it. It says how far the work moved from where it was declared, not what the moves cost.
RIGHT BANK · underwriter
A filed rate or a loss figure: it is ADVISORY and raw, with the scope correction not yet applied. Nor does one print separate a change in behaviour from a slide of the window, which is why the whole line is drawn.
THE MITIGATION
LEFT BANK · deployer
Publish your own. The same two commands print your vega from your own tape, and 🔗 Countersign (backup) carries it to whoever reads your record.
RIGHT BANK · underwriter
Price from the line, never one print. Ask for the series and the seal and recompute both; a seal that reads BROKEN means a priced row changed outside the one writer, and the print is not evidence until it is re-sealed.
UNMEASURED — public/.well-known/semantic-vega.json is not readable at this render (ENOENT).
seal UNMEASURED — data/pmu/measure-history.ndjson is not readable at this render
+See one before you install anythingthe public record, open without an account
See one before you install anything.The public record is open without an account: a real tape, read the way a carrier would read yours. The tail of its token spend is drawn live there, recomputed from the backed-up ticks each time the page asks.
To make your own: install the ThetaCog extension (thetadriven.thetacog-mcp in the VS Code Marketplace; its MCP server alone is npx thetacog-mcp), then press 🔗 Countersign (backup), under the + on THE SECOND READER card in the ThetaCog sidebar. It writes the archive and opens this page with its manifest.
+Four desks read this recordDeployer · Underwriter or broker · General counsel · Allocator or diligence
Each desk opens the same record at its own question.
+DeployerOpen the deployer desk
Deployer. What you signed for, set beside what the tape says ran. Open the deployer desk
+Underwriter or brokerOpen the insurer desk
Underwriter or broker. Each deviation detected, placed against the scope declared before the work ran, and priced. Anything unmeasured is printed UNMEASURED. Open the insurer desk
+General counselRead the boundary
General counsel. Where the record holds and where it stops: whether the work was good is undecidable (Rice, 1953), and we do not claim it. Read the boundary
+Allocator or diligenceRead custody and failure modes
Allocator or diligence. What is stored and where, who holds which key, who can read the raw bytes, how a restore is checked, what retention is (still open, and named open), and what happens when each part fails. Read custody and failure modes
Handed a backup by someone else? How to read it without us: what arrives, the free recompute, the paid query, where the keys are, and what it is not sufficient for.
+Your accountsigned out
A receipt is written to an account. The archive and its manifest stay yours at no cost.
Sign in to upload an archive and keep a receipt for your own archive, or buy licences for the attested half.
+Already holding an archive?open this page by its manifest
Already holding an archive? This door takes /backup?manifest=<sha256> — the 64-hex name of the archive the IDE wrote to .thetacog/backup/. Press 🔗 Countersign (backup) in the IDE (under the + on THE SECOND READER card in the ThetaCog sidebar) and it opens this page with the right manifest.
Sufficient for:where it landed, re-runnable from the commit: same bytes, same hash. NOT sufficient for:whether the work was good, which is undecidable (Rice, 1953); nothing here claims it.
