@bytesbrains/cruise-worker 0.0.0-stage → 0.12.0

package/migrations/0040_glm_5_3_on_workers_ai.sql

@@ -0,0 +1,63 @@
+-- GLM-5.3 and GLM-5.3-Flash, which a host we already hold a key for now serves.
+--
+-- #122 raises GLM-5.3-Flash from the board as a candidate for `extraction` at
+-- the cheap end, sourced to z.ai's own pricing page. Cruise holds no z.ai key,
+-- so that page prices nothing we can route. Cloudflare does serve the weights —
+-- @cf/zai-org/glm-5.3 and @cf/zai-org/glm-5.3-flash are on the Workers AI
+-- pricing page, fetched 2026-08-29 UTC — which is how the last three z.ai
+-- models in this catalogue arrived (0025).
+--
+--   glm-5.3-flash   $0.150 in / $0.030 cached in / $0.500 out per M
+--   glm-5.3         $1.400 in / $0.260 cached in / $4.400 out per M
+--
+-- Both state a 1,048,576-token window and function calling on their model
+-- pages; neither states a maximum output, so `max_output` is NULL and
+-- `checkLimits` derives a bound from the window (0023). Same rules as 0025:
+-- every number quoted from the host's own page, anything the host does not
+-- state stays NULL.
+--
+-- The board's `conditional_prices` warning does not reach these rows, and the
+-- reason is worth writing down. z.ai launched GLM-5.3-Flash on a promotion —
+-- half list, ending 24:00 on 2026-09-09 UTC+8 — which is exactly the shape
+-- 0024 exists for: a member that wins a lane today and stops on a known date
+-- with no announcement to trigger a re-check. Cloudflare charges $0.150 /
+-- $0.500 flat, and that is z.ai's *post*-promotional list rate, not the
+-- promotional one. There is no date-bounded rate on this row to express. If a
+-- z.ai key is ever held, `deepseek/…` is not the only model with a `peak_utc`
+-- row and this one gets a dated pair too.
+--
+-- Not added to any lane. Both are "not available through standard Workers Free
+-- billing" on their pages, which is the entitlement wall five other Workers AI
+-- rows already sit behind, and neither has been measured — 0029 puts a model in
+-- a lane only once it is routable in production. Inserting is not admitting
+-- (0025): conformance writes `measured_at`, and until it does, `/v1/models`
+-- and every lane leave these out on their own.
+--
+-- What the board is actually proposing, priced: glm-5.3-flash is *not* the
+-- cheap end of `bb/extraction`. granite-4.0-h-micro ($0.017 / $0.112) and
+-- ministral-8b ($0.15 / $0.15) both undercut it, and allocation is price-first,
+-- so on an ordinary extraction request it would never be picked. Where it
+-- would win is the request those two cannot take at all: its window is
+-- 1,048,576 tokens against granite's 131,000 and ministral-8b's 262,144, so it
+-- is a long-input candidate for this lane rather than a cheap one. That is an
+-- argument for measuring it, not for assuming the board's ranking transfers to
+-- a lane that ranks on price.
+--
+-- Not a re-sweep of the Workers AI catalogue. Those rows were fetched
+-- 2026-08-21 and some of them have moved since; that is its own pass, against
+-- every row at once, so that one dated fetch backs the whole table.
+
+INSERT INTO models (id, upstream_id, upstream_model, max_context) VALUES
+  -- https://developers.cloudflare.com/workers-ai/models/glm-5.3/
+  ('workers-ai/@cf/zai-org/glm-5.3',       'workers-ai', '@cf/zai-org/glm-5.3',       1048576),
+  -- https://developers.cloudflare.com/workers-ai/models/glm-5.3-flash/
+  ('workers-ai/@cf/zai-org/glm-5.3-flash', 'workers-ai', '@cf/zai-org/glm-5.3-flash', 1048576);
+
+INSERT INTO model_prices
+  (model, effective_from, input_micros_per_mtok, output_micros_per_mtok,
+   cached_input_micros_per_mtok, source)
+VALUES
+  ('workers-ai/@cf/zai-org/glm-5.3',       '2026-08-29', 1400000, 4400000, 260000,
+   'https://developers.cloudflare.com/workers-ai/platform/pricing/'),
+  ('workers-ai/@cf/zai-org/glm-5.3-flash', '2026-08-29',  150000,  500000,  30000,
+   'https://developers.cloudflare.com/workers-ai/platform/pricing/');

package/migrations/0041_mistral_sweep_2026_08_29.sql

@@ -0,0 +1,89 @@
+-- The catalogue re-read against every host page, and the two rows that had
+-- quietly stopped agreeing with theirs.
+--
+-- 0040 deferred this and said why: the Workers AI rows were fetched 2026-08-21
+-- and nothing had re-read them since, which is the condition under which
+-- DeepSeek's window was wrong for a fortnight (0039). All 38 rows were checked
+-- on 2026-08-29 UTC against the host's own page or the host's own API.
+--
+-- **No price moved.** Workers AI 25 of 25, Mistral 9 of 9, DeepSeek 3 of 3 —
+-- every figure in `model_prices` is the figure its host prints today. That is
+-- the useful half of a sweep and it is why the dates are worth carrying: the
+-- rows are not stale, they are confirmed, and the next reader can see which.
+--
+-- Two rows were wrong in a way price-watching would never have caught.
+--
+-- ── mistral-small-latest has no cached-input rate ─────────────────────────────
+--
+-- Every other Mistral row carries one, at the 10% the pricing page prints in
+-- its own cached-input column. This row came from 0020/0021 — before 0025 read
+-- that column — and has billed cache hits at the **full** input rate ever
+-- since. $0.15 where the host charges $0.015, ten times over, on every hit.
+--
+-- It over-counts, which is the safe direction and is why nothing noticed: the
+-- budget stops early, never late, and no request was served that should not
+-- have been. It is still a customer charged for something they did not use, and
+-- #98 bills a cache hit as a published fraction of list — so a wrong list makes
+-- the published fraction a wrong promise rather than a wrong number.
+--
+-- Corrected in place. The rate was never right, so a new `effective_from` would
+-- claim Mistral changed something on 2026-08-29; 0011 and 0039 both corrected a
+-- misquoted figure this way. A rate that genuinely moves still arrives as a new
+-- dated row beside this one, which is the whole point of the column — correcting
+-- a misquote and recording a change are different acts and the table says which
+-- by which of the two it did.
+--
+-- `source` moves with it, from the model card 0021 cited to the pricing page.
+-- Not cosmetic: the card states input and output and no cached rate, so a row
+-- carrying all three cannot honestly name it. The pricing page states all three,
+-- so one URL now covers every number on the row — which is what `source` is for
+-- and what 0011 changed it from an adjective to a URL to make possible.
+--
+-- ── labs-leanstral-1-5 is an alias, not an id ─────────────────────────────────
+--
+-- Mistral's API answers `labs-leanstral-1-5` with `aliases: ["labs-leanstral-1-5-1"]`
+-- — it is the moving name and `-1-5-1` is the pinned one. 0025's own rule says
+-- to pin the dated id the host lists, because an alias moving is a rate change
+-- with no signal (0020), and it caught every `-latest` on the page. This one is
+-- not spelled `-latest`, so it walked past the rule and past the test that
+-- enforces it, which only ever looked for that suffix.
+--
+-- The model is free, unmeasured and in no lane, so nothing has been billed
+-- wrong. What it would have cost is the next thing: Labs preview, free today,
+-- and an alias that moves to a priced version is a price change from 0 with
+-- nothing to announce it.
+--
+-- ── Checked and unchanged, so nobody re-checks them next week ────────────────
+--
+--   Workers AI, 25 rows, https://developers.cloudflare.com/workers-ai/platform/pricing/
+--   — every input, output and cached figure identical to 0025 and 0040. Seven
+--   models are marked paid-billing-only: kimi-k2.6, kimi-k2.7-code, glm-5.2,
+--   glm-5.3, glm-5.3-flash, deepseek-v4-flash-0731, deepseek-v4-pro-0813.
+--   Nothing new to add — the other rows on that page are earlier generations
+--   0025 already excluded.
+--
+--   DeepSeek, 3 rows — unchanged, and the peak framing re-read in full for
+--   0039. Nothing on that page moved this pass.
+--
+--   The two card-versus-API conflicts 0025 resolved by taking the smaller are
+--   both still live and still resolved the same way: codestral's card says
+--   128k against the API's 256000, ministral-3b's card says 256k against the
+--   API's 131072. Refusing a request the host would have taken is visible and
+--   correctable; passing one it would not is neither.
+--
+--   `zai-glm-5-2` is absent from Mistral's `GET /v1/models` for this account
+--   but answers `GET /v1/models/zai-glm-5-2` with a 200 and a 1,048,576-token
+--   window, which is the figure on the row. The list endpoint is scoped to what
+--   the account may call, so absence from it is an entitlement fact, not a
+--   withdrawal. Worth writing down before someone reads a short list as a
+--   retirement.
+
+UPDATE model_prices
+   SET cached_input_micros_per_mtok = 15000,
+       source = 'https://docs.mistral.ai/inference/pricing'
+ WHERE model = 'mistral/mistral-small-latest'
+   AND cached_input_micros_per_mtok IS NULL;
+
+UPDATE models
+   SET upstream_model = 'labs-leanstral-1-5-1'
+ WHERE id = 'mistral/labs-leanstral-1-5';

package/migrations/0042_provision_service_keys.sql

@@ -0,0 +1,50 @@
+-- A service key that can provision a tenant and do nothing else (#140).
+--
+-- The gap: #124 shipped `provisionTenant` and one caller, `npm run
+-- tenant:provision` — a person at a terminal holding a Cloudflare API token,
+-- one customer at a time. `dashboard#369` names that as blocker 1 on
+-- the flow customers buy credits through, and its own summary is the right one:
+-- survivable for the first customers and not beyond that.
+--
+-- Why a service key rather than a route under /admin. `authorize()` resolves a
+-- tenant and a role from `memberships` keyed by uid, and a customer signing up
+-- has no row to resolve — the request that would create one cannot be
+-- authorised by the thing it is about. The status notes recorded that as the reason
+-- there is no route; it is still the reason, and it is why this arrives on the
+-- payments plane instead. src/tenants.ts said as much during #124's review:
+-- `provisionTenant` "exists to be called by the payments-plane route when
+-- signup does".
+--
+-- `purpose` gains a third value on 0038's terms, not beyond them: one
+-- capability per key, issued for one value and never two. `credits` grants and
+-- reconciles; `balance` reads one tenant's wallet; `provision` creates a tenant
+-- and opens nothing else. A `credits` key is refused here for 0038's own
+-- reason turned around — minting into a namespace and creating the namespace
+-- are separate powers, and a compromised granting key must not also be able to
+-- manufacture the tenants it grants into.
+--
+-- SQLite cannot widen a CHECK in place, so the table is rebuilt, and 0038's
+-- note on why that is safe applies unchanged: the name and every column stay
+-- identical, so code deployed before this migration and code deployed after
+-- read exactly the same shape. The rule 0035 taught the hard way is not "never
+-- rebuild" — it is "leave no window where deployed code queries something that
+-- is not there", and a constraint-only change leaves none. Widening is also the
+-- safe direction on its own: no existing row can fail the new CHECK, and a
+-- Worker deployed before this simply never matches a `provision` row, because
+-- `authenticate` names the purposes it will accept in the lookup itself.
+CREATE TABLE service_keys_new (
+  id         TEXT PRIMARY KEY,
+  prefix     TEXT NOT NULL UNIQUE,
+  key_hash   TEXT NOT NULL,
+  purpose    TEXT NOT NULL CHECK (purpose IN ('credits', 'balance', 'provision')),
+  created_by TEXT NOT NULL,
+  created_at TEXT NOT NULL DEFAULT (datetime('now')),
+  revoked_at TEXT,
+  last_used_at TEXT
+);
+
+INSERT INTO service_keys_new (id, prefix, key_hash, purpose, created_by, created_at, revoked_at, last_used_at)
+SELECT id, prefix, key_hash, purpose, created_by, created_at, revoked_at, last_used_at FROM service_keys;
+
+DROP TABLE service_keys;
+ALTER TABLE service_keys_new RENAME TO service_keys;

package/migrations/0043_tier_project_quota.sql

@@ -0,0 +1,32 @@
+-- How many projects a tier allows (#140 follow-on, 0034).
+--
+-- The hole this closes is arithmetic, not policy. A budget is **per project**:
+-- `budgets` rows are keyed `scope='project'`, and `reserveBudget` folds the
+-- check into one UPDATE against that row. There is no cap on their sum. So a
+-- tenant that can create projects without limit can spend without limit — one
+-- hundred projects on the starting $5.00/day cap is $500.00/day, every cap
+-- individually honoured and the total unbounded.
+--
+-- That was harmless while the only way to get a second project was somebody
+-- running SQL. `POST /admin/projects` makes it a customer's own decision, so
+-- the number needs a ceiling before the route exists rather than after.
+--
+-- The figures follow the lane quotas' shape — enough to be useful on Free,
+-- generous on Pro, unlimited on Enterprise. A project is a heavier object than
+-- a lane (it holds keys, a budget and a gateway), so the counts are lower.
+--
+-- Null is unlimited, as with `lanes` and `members_per_lane`. An id `tiers` does
+-- not know already falls back to Free in `tierOf`, so this column inherits that
+-- fail-closed behaviour with no extra code.
+ALTER TABLE tiers ADD COLUMN projects INTEGER CHECK (projects IS NULL OR projects >= 1);
+
+UPDATE tiers SET projects = 1    WHERE id = 'free';
+UPDATE tiers SET projects = 5    WHERE id = 'core';
+UPDATE tiers SET projects = 25   WHERE id = 'pro';
+UPDATE tiers SET projects = NULL WHERE id = 'enterprise';
+
+-- Enforced at the write and nowhere else, exactly as the lane quota is (#104).
+-- `bytesbrains` holds six projects on `enterprise` and is unaffected; a tenant
+-- that is already over a limit keeps everything it has and is refused the next
+-- create. Retroactively disabling somebody's project because a number moved is
+-- how a quota becomes an outage.

package/migrations/0044_audit_tenant_scope.sql

@@ -0,0 +1,49 @@
+-- Which tenant an audit event belongs to (#147 gap 2).
+--
+-- The dashboard can show every piece of state a tenant owns — members, keys,
+-- lanes, budgets, projects — and cannot answer "who changed it, and when".
+-- The rows exist; nothing can read them, because nothing can *scope* them.
+--
+-- Why a column rather than a join on `subject`. Every writer puts a different
+-- thing there: a tenant id, a project id, a key prefix, a uid, an intent id, a
+-- lane id. Scoping a read would mean a per-action join, one branch per action,
+-- and the branch nobody wrote is another tenant's rows served to a caller who
+-- looks correctly scoped. `admin-ledger.ts` carries that exact scar — "grouping
+-- by account or model returned every tenant's rows while looking scoped" — and
+-- the lesson from it was one column filtered in SQL, not cleverness per shape.
+--
+-- **Nullable, and null is not "everyone".** A platform event belongs to no
+-- tenant: `service_key.revoke` is about a credential the payments side holds,
+-- and there is no tenant it could be shown to. The read filters
+-- `tenant_id = ?`, so an unattributed row is invisible to every tenant rather
+-- than visible to all of them. That is the fail-closed direction, and it is the
+-- one that matters: a row we cannot attribute must never be shown to a tenant
+-- that might not own it.
+ALTER TABLE audit_events ADD COLUMN tenant_id TEXT;
+
+-- The read is "this tenant's trail, newest first", so the index matches it.
+CREATE INDEX idx_audit_tenant_at ON audit_events (tenant_id, at DESC);
+
+-- Backfill what is derivable, and leave the rest null rather than guessing.
+--
+-- Key events name a prefix, and a key belongs to a project which belongs to a
+-- tenant — the one path to that fact (0004), so this cannot disagree with
+-- itself. Membership events name a uid, and a uid may hold rows in several
+-- tenants; `detail` carries the tenant the grant was for, which is the only
+-- non-ambiguous source, so only rows that recorded it are attributed.
+UPDATE audit_events
+   SET tenant_id = (
+     SELECT p.tenant_id FROM virtual_keys k JOIN projects p ON p.id = k.project_id
+      WHERE k.prefix = audit_events.subject
+   )
+ WHERE action IN ('key.issue', 'key.revoke') AND tenant_id IS NULL;
+
+UPDATE audit_events
+   SET tenant_id = json_extract(detail, '$.tenant')
+ WHERE action = 'membership.grant' AND tenant_id IS NULL AND json_extract(detail, '$.tenant') IS NOT NULL;
+
+-- Everything else keeps null: `service_key.revoke` has no tenant, and a row
+-- whose tenant cannot be established from the data is not going to be improved
+-- by a guess. There are fourteen audit rows on production as this lands, so the
+-- history being partly unattributed costs nothing; every row written from here
+-- carries its tenant.

package/migrations/0045_audit_backfill_derivable.sql

@@ -0,0 +1,42 @@
+-- The rest of the trail that could have been attributed, and was not (#147).
+--
+-- 0044 backfilled key events and membership grants and stopped there. Applying
+-- it to staging showed what that left behind: **29 of 79 rows** whose tenant
+-- was sitting one join away.
+--
+--     budget.set    5   subject is a project id
+--     credit.*     24   subject is a payment intent id, and `credits` holds it
+--
+-- Production happened to have none of those yet, which is exactly why it was
+-- not noticed when the migration was written — the environment it was checked
+-- against had only key and membership history.
+--
+-- It matters more than a tidiness fix. the dashboard's argument for this
+-- route was that it is the one gap that **gets worse with time rather than
+-- staying the same size**, because a trail's value is entirely retrospective.
+-- Shipping it with a third of the recoverable history unattributed gives away
+-- the thing being built.
+--
+-- Both derivations are single-path, so neither can disagree with itself:
+-- `budgets.subject` is a project id and a project belongs to one tenant (0004);
+-- `credits.payment_intent_id` is a primary key and each row names its tenant.
+-- A row whose join finds nothing keeps its null rather than taking a guess —
+-- a refused credit may have no `credits` row at all, which is correct and
+-- stays unattributed.
+UPDATE audit_events
+   SET tenant_id = (SELECT p.tenant_id FROM projects p WHERE p.id = audit_events.subject)
+ WHERE action = 'budget.set'
+   AND tenant_id IS NULL
+   AND EXISTS (SELECT 1 FROM projects p WHERE p.id = audit_events.subject);
+
+UPDATE audit_events
+   SET tenant_id = (SELECT c.tenant_id FROM credits c WHERE c.payment_intent_id = audit_events.subject)
+ WHERE action LIKE 'credit.%'
+   AND tenant_id IS NULL
+   AND EXISTS (SELECT 1 FROM credits c WHERE c.payment_intent_id = audit_events.subject);
+
+-- Still null afterwards, and correctly so: `service_key.revoke` is a platform
+-- credential and belongs to no tenant; `membership.revoke` names a uid, and a
+-- uid may hold rows in several tenants with nothing on the row to say which.
+-- A guess there would attribute somebody's revocation to the wrong account,
+-- which is worse than leaving it out of every trail.

package/migrations/0046_measurement_note.sql

@@ -0,0 +1,24 @@
+-- Why a model has no measurement, when the reason is knowable (#149).
+--
+-- `measured_at IS NULL` means one of two very different things today, and the
+-- refusal cannot tell them apart:
+--
+--   never measured        conformance has not reached it yet
+--   cannot be measured    the provider refuses our credentials, and no number
+--                         of runs will change that
+--
+-- The second was invisible in a worse way still. When every check on a model
+-- errors, `flagsFromResults` decides nothing, the `UPDATE` is skipped, and
+-- `measured_at` keeps its old date — so a model the provider has stopped
+-- serving reads as **verified** for up to thirty more days and then goes stale
+-- with `measurement_stale`, which says "conformance has not run". It will have
+-- run three times.
+--
+-- `mistral/mistral-large-2512` is in exactly that state on production as this
+-- lands: reachable on 2026-08-22, 403 on every check on 2026-08-31, still
+-- carrying the August date and still a member of `bb/code-review`.
+--
+-- So the note holds the sentence a refusal should say. Null for every model
+-- that has simply not been measured, which is the state ten rows are in today
+-- and which needs no explanation.
+ALTER TABLE models ADD COLUMN measurement_note TEXT;

package/migrations/0047_ledger_max_tokens.sql

@@ -0,0 +1,21 @@
+-- The caller's own cap on output, kept beside what the request cost (#142).
+--
+-- Production spends a third of its money on requests that returned nothing,
+-- and sixty of those rows have `completion_tokens` exactly equal to
+-- `reasoning_tokens` — the model spent its entire output budget thinking and
+-- emitted no content. The suspected cause is a `max_tokens` too small for a
+-- reasoning model, and the reason it is still *suspected* is that the ledger
+-- has never recorded what the caller asked for.
+--
+-- So the hypothesis cannot be tested against the eight hundred rows that would
+-- settle it. This column is the difference between an argument and a query.
+--
+-- Nullable, and null is not zero. Null means **the caller stated no cap** and
+-- the model's own default applied, which is a distinct and interesting case:
+-- a reasoning model left to its own defaults is a different failure from one
+-- squeezed into 256 tokens, and the fix for each is different too.
+--
+-- Not backfillable. Every row already written has lost the figure, so the
+-- question is answerable from the day this deploys and not before — which is
+-- an argument for landing it rather than for widening it later.
+ALTER TABLE ledger ADD COLUMN max_tokens INTEGER;

package/migrations/0048_price_observations.sql

@@ -0,0 +1,140 @@
+-- What we believed a price was, and when we believed it (#18).
+--
+-- `model_prices` already answers *"what did this model cost on 2026-08-20"* —
+-- `effective_from` is in the primary key and `resolvePrice` takes
+-- `max(effective_from) WHERE effective_from <= ?`. That half of #18 has been
+-- built since 0024 and this migration does not change it.
+--
+-- What it cannot answer is **"what did we think it cost on 2026-08-20"**, and
+-- those are different questions whenever we were wrong. Five migrations have
+-- mutated this table in place:
+--
+--   0011  a Workers AI rate that had been misquoted
+--   0014  a rate corrected alongside the ledger
+--   0021  DELETE + re-insert: an effective date recorded in the wrong timezone
+--   0039  DeepSeek's peak window, which was always weekdays and was recorded
+--         without days — the one that over-charged every weekend for a fortnight
+--   0041  a Mistral cached-input rate that had been left NULL
+--
+-- Every one is a **correction** rather than a price change, and each was right to
+-- make. But each also erased the belief it replaced, and that belief is what
+-- explains the rows written under it. #122 hit this directly: production ledger
+-- rows from 2026-08-16 to 2026-08-29 carry a 2x DeepSeek over-count, and the
+-- table can no longer show the window that produced them. The explanation lives
+-- in a commit message.
+--
+-- It is load-bearing beyond archaeology. #21's displacement number asks what a
+-- static day-one pin *would have cost*, and #18 says a savings claim that cannot
+-- separate "we routed better" from "the price moved" is not a savings claim. A
+-- correction and a price change look identical in a mutable table, so today it
+-- cannot separate them from the data at all.
+--
+-- ## The shape
+--
+-- Two time axes, which is the whole point:
+--
+--   effective_from  when the **vendor's** rate applied. Unchanged in meaning.
+--   observed_at     when **we** recorded it. New, and the axis that was lost.
+--
+-- A correction is an append with a later `observed_at` and the same
+-- `effective_from`. A price change is an append with a new `effective_from`. The
+-- two are now distinguishable, which they were not.
+--
+-- ## Why `model_prices` becomes a view rather than gaining a companion table
+--
+-- A companion table is a discipline: every future migration must remember to
+-- write both, and the one that forgets is silent. This repo has an invariant
+-- about exactly that shape — tenant isolation is schema-enforced rather than
+-- conventional, so two columns cannot disagree. The same argument applies here,
+-- and a view cannot be written to, so "overwritten in place" stops being
+-- possible rather than becoming discouraged.
+--
+-- **The cost, stated plainly:** a future `INSERT INTO model_prices` fails with
+-- *"cannot modify model_prices because it is a view"*. That is a loud failure at
+-- the moment of writing, caught by `npm test` since the suite runs the real
+-- migrations — and the message names its own fix. Write to `price_observations`.
+--
+-- Every reader is unchanged. All ten call sites across `pricing.ts`,
+-- `routing.ts`, `ledger.ts` and `report.ts` are SELECTs, and the view presents
+-- the same columns under the same names.
+--
+-- ## Retraction, because a correction sometimes removes a row
+--
+-- 0021 deleted a row whose `effective_from` was a day out. Append-only has no
+-- delete, so `retracted` is the tombstone: the latest observation for a key can
+-- say "this key should not exist", and the view drops it. Without this the next
+-- correction of that shape would have to DELETE from the log, which would defeat
+-- the table.
+--
+-- ## What is not backfilled, and why that is honest
+--
+-- The beliefs the five migrations above replaced are **not** reconstructed. They
+-- exist in git history, not in any database, and inventing an `observed_at` for
+-- them would manufacture a record that was never taken. Every existing row is
+-- copied with its own `recorded_at` as its `observed_at`, which is a fact we
+-- hold. The log therefore begins today for corrections and reaches back
+-- correctly for effective dates — the same limit 0047 stated rather than papered
+-- over.
+
+CREATE TABLE price_observations (
+  -- When we recorded this. The axis that did not exist.
+  observed_at                  TEXT    NOT NULL DEFAULT (datetime('now')),
+
+  model                        TEXT    NOT NULL,
+  -- When the vendor's rate applies. Same meaning as before.
+  effective_from               TEXT    NOT NULL,
+  prompt_tokens_from           INTEGER NOT NULL DEFAULT 0,
+  peak_utc                     TEXT    NOT NULL DEFAULT '',
+
+  input_micros_per_mtok        INTEGER NOT NULL,
+  output_micros_per_mtok       INTEGER NOT NULL,
+  cached_input_micros_per_mtok INTEGER,
+
+  source                       TEXT    NOT NULL,
+  -- Why this observation was taken. Free text, and the place a correction says
+  -- what it is correcting — the sentence that otherwise only exists in a commit.
+  note                         TEXT,
+  -- 1 means "this key should not exist". The view drops it.
+  retracted                    INTEGER NOT NULL DEFAULT 0 CHECK (retracted IN (0, 1)),
+
+  PRIMARY KEY (model, effective_from, prompt_tokens_from, peak_utc, observed_at)
+);
+
+-- The resolver reads by model and effective date on every priced request.
+CREATE INDEX idx_price_observations_lookup ON price_observations (model, effective_from);
+
+-- Every row we hold today, carrying the one thing we honestly know about when it
+-- was taken.
+INSERT INTO price_observations
+  (observed_at, model, effective_from, prompt_tokens_from, peak_utc,
+   input_micros_per_mtok, output_micros_per_mtok, cached_input_micros_per_mtok, source, note)
+SELECT recorded_at, model, effective_from, prompt_tokens_from, peak_utc,
+       input_micros_per_mtok, output_micros_per_mtok, cached_input_micros_per_mtok, source,
+       'Carried in from model_prices by 0048. Its value is current; any belief it replaced is in git history, not here.'
+  FROM model_prices;
+
+DROP TABLE model_prices;
+
+-- The latest surviving observation per price key. `recorded_at` is kept under
+-- its old name so no reader has to change; it is now the observation's date
+-- rather than the row's last write, which is what it was always meant to be.
+CREATE VIEW model_prices AS
+SELECT o.model,
+       o.effective_from,
+       o.prompt_tokens_from,
+       o.peak_utc,
+       o.input_micros_per_mtok,
+       o.output_micros_per_mtok,
+       o.cached_input_micros_per_mtok,
+       o.source,
+       o.observed_at AS recorded_at
+  FROM price_observations o
+ WHERE o.retracted = 0
+   AND o.observed_at = (
+         SELECT max(x.observed_at)
+           FROM price_observations x
+          WHERE x.model              = o.model
+            AND x.effective_from     = o.effective_from
+            AND x.prompt_tokens_from = o.prompt_tokens_from
+            AND x.peak_utc           = o.peak_utc
+       );