Methodology

How the Quota Reset Index records events and how it forecasts them — including what it cannot do, and what it would take to fix that.

The ledger comes first

The ledger is the asset. It records discretionary quota resets with evidence links and a confidence grade, and it makes no predictions, so it cannot be wrong in the way a forecast can. The forecasts below sit on top of it and are strictly the less trustworthy half of this project.

An audit on 2026-07-26 found that 24 of 29 records carried at least one over-claimed enrichment field — a scope or trigger value that no source asserted of that specific event. The events themselves survived: every record's vendor, date and evidence held up under adversarial review, and six candidate events were rejected before entry. The defects were in the metadata around them.

That correction has landed. Every accepted change was written as a superseding record; nothing was edited in place and nothing was deleted. Two details worth stating, because they are the reason to believe the rest:

• The 41 proposed corrections were themselves put through an adversarial pass before any record moved. 21 of the 41 were wrong — 11 "corrected" values that were already right, and 10 would have replaced a real defect with a different unsupported claim. Had they been applied as drafted, the ledger would have looked audited while staying wrong.
• That pass also found two structural defects nobody had asked it to look for: one event recorded twice under two timezone conventions, and a citation whose own identifier decoded to a date four days from the one it was filed under. Both are fixed; both are visible in the record chain.

The root cause was a schema property rather than 24 careless judgments. A required boolean cannot say "we do not know", so nine records asserted account coverage no source had addressed. Fields can now be explicitly unestablished, and every enrichment field carries a provenance marker.

Model A — Codex: self-exciting intensity

Codex quota state is not observable from outside, so the reset history is the richest signal available. Resets arrive in bursts, which is the signature of a self-exciting process rather than a memoryless one — hence a Hawkes intensity with a short refractory dip.

λ(t) = [ μ + α·e^(−Δt/τ) ] · refractory(Δt) · exp( Σ wⱼ·sⱼ·2^(−ageⱼ/hlⱼ) )

P(reset within W) = 1 − exp( −∫₀^W λ dt )

The behaviour most likely to look like a bug: a reset 2 hours ago lowers the instantaneous rate but raises the 48-hour probability. That is deliberate — excitation outlives the refractory dip, and same-day repeats happened twice in July 2026. A change that reverses it is a regression, and a test pins it.

Codex evidence weights

Model B — Claude Code: renewal hazard with covariates

Claude Code exposes usage state, so it can in principle be instrumented — which is why it gets a different model rather than the same one twice. It reports two numbers because the vendor offers two knowable things: a near-deterministic scheduled recycle, and a genuinely uncertain discretionary reset. They are different questions and must never be added together.

λ(t) = λ₀ · D(utilisation) · K(day, hour) · exp( Σ wⱼ·sⱼ·2^(−ageⱼ/hlⱼ) )

D(u) = 1 + 1.7 / (1 + e^(−(u − 0.74) / 0.075))

scheduled: Φ((W − t_due) / σ),  σ = 0.6h,  period ≈ 72h

Calendar term

This is the only clock-dependent term in either model, and it is why the Claude Code figures move between a Tuesday and a Saturday on otherwise identical inputs.

Base rates

Integration is a midpoint rule at 0.25h steps over a 96h horizon. Midpoint rather than left-endpoint because both models are steep near t=0 and a left-endpoint sum would bias the short windows.

What the sentinel depends on, and how it fails

§8 requires this stated plainly, so:

The data, and how to use it

Both files are regenerated from the flat record files by a deterministic build — same inputs, byte-identical output — and are never hand-edited. They are served CORS-open because the point is for other people to check our work.

Four things a consumer needs to know:

• Superseded records are included. Filter on superseded_by === null for the current view. They are present rather than removed because the correction chain is the audit trail — a ledger that deletes its own history is asking to be believed rather than checked.
• field_support tells you what to trust. Per enrichment field: attested (a source states it of that event), inferred (it follows from a general statement, nobody asserted it here), unestablished (nothing addresses it). A field with no marker predates 2026-07-26 and its provenance was never recorded.
• scope.partial: null means unestablished, and is distinct from false. In the CSV it renders as an empty cell rather than the string "false".
• Dates are UTC. Several widely-cited secondary sources date these events in US Pacific, which puts some of them on the previous day. Where a record's identity depends on that, the underlying post id and its decoded UTC timestamp are recorded in the notes.
• Evidence carries an archive link where one exists. Each evidence item may have an archive_url and an archive_timestamp, so the claim you can check is "as of that date, this source said this" rather than "this URL currently resolves". Where a source cannot be archived — some hosts refuse it — the fields are absent rather than faked, and that refusal is itself recorded.

Why the archive lives beside the records, not inside them

The record files are append-only: once committed, every field except superseded_by is sealed, and a pre-commit hook plus a CI check against full history enforce it. Writing an archive link into a committed record would be a mutation, and the hook rejects it.

So archives live in their own append-only index, keyed by URL, and are joined into the published files at build time. This is not a workaround for the guarantee — it is a better fit for the data. An archive is not a claim about the event; it is a durability measure for a citation, with its own lifetime. A single field holds one capture, whereas the index holds a series of attempts, successes and failures alike. That is what supports a dated claim rather than a current one.

How this becomes citable rather than interesting

The build order is fixed: ledger, then sentinel, then models, then this page. Calibration is blocked on roughly 40 labelled events per vendor. When that unblocks, the work is maximum-likelihood fitting against the ledger with a held-out window, and a Brier score published beside each forecast. Until then the banner at the top of this page stays exactly where it is.