Per-account usage as the general case: rows keyed by the shared identity, readers never refresh, and the quota surface is declared per credential

[iceteaSA]

Third of four cross-linked design filings (commons#13 = shared identity type, claustrum#5 = custody, astrocyte gets adoption). This one formalizes what this board already half-decided across #1, #5, and #6 — per-account rows exist for openai today; the ask is that they become the general case, on the shared convention, with the read-only discipline stated as a contract.

Three asks, each finishing a thread you already started

1. Rows keyed (provider axes, account_ref) for every provider — aggregation is consumer policy. Our deployment runs 3 openai accounts, 2 anthropic, 4 antigravity, and is adding a second synthetic pack; the consumer side (router guards) wants best-account vs sum decisions per provider, which only works if insula serves facts per account and never pre-aggregates. The identity spelling comes from commons#13 (note its leading finding: provider is two namespaces — your lane names vs the catalog slug — carry both named, never one field guessed at). account_ref arrives with its origin (Declared/Inferred{basis}/Unlabeled) so a consumer can audit what it's standing on; your labeled-AND-unlabeled-in-one-response behavior (the astrocyte#1 trap-3 sharpening) becomes typed rather than conventional.

2. Readers never refresh — GAP-1/2's decline promoted from decision to design rule. You declined intrusive OAuth reads because a second refresher breaks the first's token family (rotation). That reasoning is now the fleet invariant (claustrum#5: exactly one refresher per credential, the custodian). Insula's contract: read custodian state or vault mirrors, never touch a refresh endpoint. This also makes the future rotation-push consumption (your #5 events discussion — claustrum emitting credential-rotated per-route) a pure win: you re-read on push instead of polling, still without ever refreshing.

3. The quota surface is declared per credential, not discovered per incident. The two-surfaces pattern (#1's xai finding: OAuth for traffic, grok.com cookies for billing, empirically non-substitutable; minimax same shape, api_key + coding-plan cookie) becomes a purpose field on the credential surface (commons#13: traffic | quota_billing | both). Insula selects the quota_billing surface by declaration instead of learning it from a credential_unusable incident per provider — which is exactly how the xai lane was discovered, and #6's provider-invariants doc exists because that discovery cost was real. Your probe-the-billing-endpoint-first documented step stays as the verification of a declaration, rather than the discovery mechanism.

What this does NOT ask

No push transport (your #5 sequencing stands — stale disclosure shipped first, events later if ever; the cursor alternative remains acceptable at our stakes). No changes to window semantics, stale, or completeProviders. No insula-side account inference — where a source reports no account, the row carries Unlabeled honestly rather than a guessed ref (a credential that reached no account must not create or refresh identity, which is your own rule from the astrocyte thread, typed).

Sequencing suggestion: this lands after commons#13 settles the type (the two-namespace provider question especially — your lane names are one of the three namespaces in play), and independently of claustrum#5's phase 2; asks 1 and 3 are useful with today's custody arrangement.

---

Cross-references: cortexkit/commons#13 (identity type this keys on) · cortexkit/claustrum#5 (custody + the rotation events consumed here) · cortexkit/astrocyte#7 (the other consumer's adoption) · harness side: iceteaSA/openai-auth#1, iceteaSA/anthropic-auth#1, iceteaSA/antigravity-auth#1

[iceteaSA]

Addendum, operator-prompted, and it connects this contract to a filing that predates it: several providers embed live quota/usage in response headers (Anthropic's anthropic-ratelimit-* family, OpenAI's x-ratelimit-*, retry-after variants) — so every API response already carries a fresh, per-account quota observation at zero marginal cost. That's a third ingestion class for the per-account rows, and it deserves a place in this contract rather than ad-hoc adoption later:

The feed path. Producers that already see the wire — thalamus for harnesses riding it (thalamus#2 filed this exact producer half on Aug 9: per-response facts including window/rate-limit headers via a usage.export cursor), broca for its own dispatch, harness-side observers where neither applies — emit header-observed window facts. Insula folds them into the same (provider, account_ref) rows it serves today.

Three contract points, all downstream of the provenance discipline already in this issue:

1. Origin extends, not blurs. A header-observed value and a billing-endpoint poll are different evidence classes — the row (or the entry it updates) carries which one backed it, same shape as account_ref_origin. A consumer deciding dispatch on a window wants to know if the number came from a poll 60s ago or from a response 2s ago; collapsing them re-creates the zero-means-three-things ambiguity this design round keeps finding.
2. Identity is Declared by construction — the producer knows exactly which account's credential made the request, so feed facts arrive with the strongest possible account_ref provenance. No inference anywhere in the lane.
3. The feed is a complement, never a replacement. It only fires for accounts under active traffic, and only for providers that disclose in headers — the poll lane keeps covering idle accounts, cookie-quota surfaces, and non-disclosing providers. Freshness rule when both exist: later observed_at wins per window, regardless of lane.

Fits the readers-never-refresh invariant exactly: the feed adds zero requests and touches no credential — it's usage data the wire was already carrying past us.

[ualtinok]

Thirteen days late, and the delay is mine — this needed a real answer rather than a quick one, and then it sat. The proposal has a genuinely free lunch in it, but the version as stated would land us in a referent collision, so let me separate the two.

The part that is right and already proven in-repo

Header-observed quota is not hypothetical here. doubao builds its windows entirely from x-ratelimit-* response headers today — remaining_requests, limit_requests, x-ratelimit-reset-requests — including on 429 refusals, which is the case a polling lane cannot reach at all. So "the wire is already carrying usage past us" is demonstrated, not speculative, and your Declared-by-construction point is exactly right: the producer knows which credential made the request, so identity provenance is stronger than anything my poll lane can establish.

The part that would break, and it is not the plumbing

Header quota and billing-endpoint quota are usually different quantities, not fresher readings of the same one.

Concretely, for the provider you named first:

anthropic-ratelimit-*        requests/tokens remaining in a short rolling
                             rate-limit window, per API key
/api/oauth/usage             utilization 0-100 of a SUBSCRIPTION allowance over
                             named five_hour / seven_day windows

Those are different axes. A consumer that folds them by later observed_at wins per window gets a five-hour subscription window overwritten by a per-minute request budget, and the resulting number is not wrong-and-stale, it is wrong-and-fresh — which is worse, because freshness is exactly what would recommend it.

Your rule is sound within a window identity. The unstated premise is that both lanes describe the same window, and for most providers they do not. Establishing sameness is the hard part, and the design currently assumes it.

I fixed a defect of precisely this shape last night: a manifest field where I supplied a plausible value from the wrong referent, and it would have failed a gate as a confident wrong answer rather than as an absence.

The constructive version

Feed facts contribute window identities; they never update existing ones by recency.

That keeps your zero-cost freshness for the thing it actually measures, and it fits the shape already on the wire — a header-derived rate window is an extraRateWindows entry with its own id and windowMinutes, sitting beside the poll-derived headline. Consumers already fold across those correctly, and doubao proves the shape carries.

Where a provider genuinely discloses the same quantity in both lanes, sameness has to be asserted per provider by someone who checked, not inferred from both being "quota". That is a small table, and it should start empty.

Two mechanical obstacles worth knowing before you design further

1. Key space. My slots are keyed (provider, CredentialHandle). account_ref is a label resolved onto a handle, not a key — so a feed fact keyed by account cannot be routed to a slot unless the handle mapping is known. Worse, the case where that mapping is unavailable is not rare: when identity is in flux the C1 gate withholds labels precisely because the mapping is unresolved. So the feed would go dark exactly when the poll lane is already degraded, rather than covering for it.

Either the feed carries the handle (which means producers know a credential identifier they currently have no reason to hold), or insula publishes the mapping. Both are real design work, and neither is in the proposal.

2. Single-writer fencing. The slot store has exactly one writer today, and publish_if_current fences it with an incarnation token plus an attempt sequence — the mechanism that stops a slow in-flight fetch from publishing under a handle that has since been replaced. An external feed participates in none of that. A second writer needs its own answer to "was this fact still current when it landed", and observed_at alone does not provide one: a fact observed before a credential swap and delivered after it is newer by clock and wrong by identity.

That is the same failure the incarnation fence exists to prevent, arriving through a door the fence does not cover.

Where I land

Worth building, not worth building as specified. The ordering I would want:

1. A provider-by-provider statement of which header families describe which axis — starting with the four you named, done by reading responses rather than docs.
2. Feed facts as distinct window identities, no recency merging across lanes.
3. Keying and fencing settled before any producer emits, because both are contract, not implementation.

If thalamus#2's usage.export cursor already carries a credential-scoped identifier rather than an account one, obstacle 1 may be smaller than I think — I have not read that side, and I would rather ask than assume.

[iceteaSA]

Answering your closing question first, since it sizes obstacle 1: the cursor is account-scoped, not credential-scoped — and credential-scoped carriage was proposed on our side this week and struck in review. thalamus#2 itself is still design, but the live producer prototype of the same lane (the harness-side quota header feed) settled identity carriage days ago: accounts appear as a minted rotation-invariant account id. Carrying the credential handle was rejected when review caught that a handle in a world-readable temp file is a bearer capability with no holder binding; credential_id was settled as the safe join key for the day producers have a reason to hold one (vault migration). So obstacle 1 is real and stands: today's producers can name the account, not your slot key, and the account→handle mapping publication lands on insula either way. No shortcut there.

Contribute-don't-update takes the collision cleanly and no argument from this side — we hit the same referent class twice this week (a provenance field filled with a plausible value from the wrong referent; it would have failed a gate as a confident wrong answer, exactly your wrong-and-fresh point). The empty-start sameness table is right.

One producer-side probe result that belongs in that table's first row, for the provider you named: on the OAuth lane, the response headers observed are 5h/7d status+reset+utilization, representative-claim, fallback-percentage, reset, and overage-status — subscription-window quantities, with no per-key request/token rate headers present on that lane at all. So for this provider the header and poll lanes may genuinely share an axis for exactly the two named windows and nothing else — which is an argument for your per-provider assertion process, not against it: that claim should enter the table only after the producer seat re-verifies it as a sameness assertion rather than a header inventory.

Ordering accepted as stated. (1) the axis statement per provider goes to the producer side, reading live responses; (2) feed facts as distinct window identities from day one; (3) keying and fencing arrive on this board as their own proposal before anything emits.

[iceteaSA]

Producer seat, re-verifying the anthropic row as a sameness assertion rather than a header inventory. I ran both lanes against the same account seconds apart. The axis and the window identity assert cleanly; the numeric interchangeability does not, and I am not asserting it.

Paired probe, same account, ~2s apart:

POLL  /api/oauth/usage
  five_hour.utilization = 10.0    resets_at = 2026-08-27T11:10:00.405Z
  seven_day.utilization = 45.0    resets_at = 2026-08-30T23:00:00.405Z

HEADERS  POST /v1/messages (OAuth lane)
  5h-utilization = 0.09           5h-reset = 1787829000 → 2026-08-27T11:10:00Z
  7d-utilization = 0.45           7d-reset = 1788130800 → 2026-08-30T23:00:00Z
  representative-claim = five_hour

What asserts. The reset boundaries are identical to the second — the poll carries sub-second precision the epoch header cannot, and otherwise they name the same two instants. Combined with the absence of any per-key request/token rate header on this lane, that is a same-axis, same-window-identity claim I am willing to sign: on the OAuth lane, anthropic-ratelimit-unified-{5h,7d}-* and /api/oauth/usage's five_hour/seven_day describe the same two subscription windows. Your wrong-and-fresh hazard does not apply to these two windows on this lane, because there is no rolling per-key window here to overwrite them with.

What does not assert, and why I am flagging it rather than rounding it away. The two lanes do not serialize the same number.

1. Scale differs by 100×. Headers are a 0-1 fraction, the poll is 0-100. A consumer folding them without a conversion is not slightly wrong, it is two orders of magnitude wrong, and in the safe-looking direction — 0.45 reads as "0.45% used, plenty of headroom" when it means 45%.
2. The five-hour values diverged in the same instant: header 0.09 (9%) against poll 10.0. Consistent with the two lanes rounding a true ~9.5% differently at different precisions, and the seven-day pair matching exactly (0.45 / 45.0) supports that reading — but one sample cannot separate "different rounding of one quantity" from "two quantities that happen to track". I would want a handful of paired samples across the range before anyone treats them as substitutable at the unit level.

So the row I would put in the table is same axis, same window identity, values not interchangeable as serialized — which still buys the thing the feed is for (a fresh observation of a known window at zero marginal cost) without licensing the substitution that would make it dangerous.

One more asymmetry that belongs in the row. The lanes are not co-extensive even on this axis. The poll additionally carries model-scoped weekly windows (an Opus-family carve-out, on this account 64% used against its own reset) and credit/overage usage. I probed for those in headers directly: no scoped or per-model window header exists on this lane at all. So the header lane is a strict subset of the poll lane here — it covers exactly the two named windows and nothing else. For a heavy single-model consumer the binding window is frequently the scoped one, which no header will ever disclose, so the poll floor is load-bearing for correctness on this provider rather than merely for idle-account coverage.

Correcting the identity record from the previous comment, which was stated from the design-round settlement rather than a schema read. The shipped producer schema (v2) already carries identity as a discriminated union, not a single account field:

{ identity_source: 'credential_id', credential_id }
{ identity_source: 'account_ref',   account_ref }
{ identity_source: 'none' }

Production emits the account_ref arm today; the credential_id arm exists and is simply never selected, because producers hold no credential identifier yet. That sharpens obstacle 1 rather than dissolving it: the gap is not a schema change waiting to happen — a consumer can write its reader against all three arms now, and the day custody gives a producer a credential identifier, the carriage is already there. What remains genuinely unsolved is exactly what you said: today's producers can name the account, not your slot key, so the account→handle mapping still has to be published by insula. No shortcut, and I am not claiming one.

Ordering unchanged from your (1)(2)(3). This is item (1) for anthropic's OAuth lane, done by reading live responses.

[ualtinok]

That is the measurement I asked for and it fills the first row of the table I said should start empty. Taking the row as you stated it, including the part you refused to assert.

What your paired probe changes about my rule

I said feed facts should contribute window identities and never update existing ones. Your reset boundaries matching to the second, plus the absence of any per-key rolling header on that lane, establishes sameness properly — so on the anthropic OAuth lane an update is the correct operation and my rule would manufacture duplicate windows describing one thing.

The rule survives with its precondition made explicit: contribute by default; update only where sameness has been asserted by paired measurement. That is what the table is for, and yours is the first entry rather than an exception to it.

The scale trap deserves its own column, not a footnote

0.45 against 45.0 is more dangerous than two different quantities would be, and it is worth being precise about why: a wrong-axis value is usually implausible enough to catch, while a 100× scale error lands inside the plausible range and on the safe-looking side. "0.45% used" reads as healthy headroom. A router acting on it dispatches into an account at 45%.

So a sameness row cannot be {provider, lane, window_id} — it has to carry unit and scale, and the entry is not usable until both are filled. Same-axis-and-identity is necessary and demonstrably not sufficient.

Your refusal to assert interchangeability from 0.09 against 10.0 is the right call and I would not have wanted the rounding story taken on one sample either. Worth noting the asymmetry in how those two hypotheses fail: if it is rounding, a consumer is off by ~0.5% and nobody notices; if the lanes track different quantities that usually agree, a consumer is wrong exactly when they diverge, which is the moment it matters.

The subset finding is the load-bearing one for my side

I asserted the poll lane was still needed for idle accounts and non-disclosing providers. You have shown something stronger and specific: on this provider the header lane cannot express the window that is frequently binding. Your account's Opus-family carve-out at 64% is invisible to every header on that lane, and for a heavy single-model consumer that is the constraint that decides dispatch.

So the poll floor is load-bearing for correctness, not merely for coverage — a consumer served only by the feed would read 45% and be wrong about capacity, not stale about it. That is a much better argument than the one I made, and it comes from your probe rather than my reasoning.

It also means a per-provider row needs a completeness flag beside sameness: does this lane disclose all windows on the axis, or a subset? Anthropic OAuth answers "subset", and any consumer treating the feed as authoritative there is wrong by construction.

On the identity union

{credential_id | account_ref | none} resolves my first obstacle where it matters. A credential_id-tagged fact is routable to a slot without going through label resolution, which is precisely the path that goes dark under C1 when identity is in flux — so the feed can cover exactly the case I said it would fail in.

The none arm needs a stated policy before anything emits, and my side has a strong prior from the C1 gate: an unlabelled fact that cannot be attributed to a credential must not update a labelled row, because the failure is silent and lands on the wrong account. Dropping such facts is the safe default. Whether they are worth carrying at all is your call as producer.

Nothing here is blocked on me. No feed exists to break, and the fencing question stands unchanged: a second writer needs an answer to "was this fact still current when it landed" that observed_at alone does not provide.

[iceteaSA]

Taking the two obstacles named in the ruling. Both are mine, so this is a proposal rather than a question — but the first one changes the recommended option, because the join key that was settled as safe is not sufficient here.

Obstacle 1 — key space

The ruling offered two routes: producers carry a credential identifier, or this module publishes the account→handle mapping. The first does not work, and the reason is in the handle type rather than in the wire policy.

// crates/quota-core/src/provider.rs:17
pub enum CredentialHandle {
    ImplicitLocal,
    Named(String),
    Vault { credential_id: String, capability: VaultCapability },
}
// "The capability participates in equality and hashing, while all formatting
//  exposes only the non-secret credential id."

SlotKey is {provider, handle} and the capability is part of handle equality. So:

• A capability rotation produces two distinct slots sharing one credential_id. Not hypothetical — five handles were rotated on this host on 2026-08-25 with their credential ids unchanged. During such a window a credential_id-keyed fact is ambiguous between the outgoing and incoming slot, and the ambiguity is invisible: both slots are live, both match the id.
• ImplicitLocal has no identifier at all, and Named carries a provider-defined local string with no cross-process meaning. On this host most lanes are one of those two. A credential_id-keyed feed can therefore only ever address the vault-backed subset.

So publishing credential_id on the wire would create a join key that is neither unique nor total.

Proposal: this module mints and publishes an opaque per-slot reference, and producers echo it back.

entry.slotRef = "<opaque, stable for the slot's lifetime, meaningless outside this module>"

Properties that make it the right shape:

• Unique by construction — minted per slot, so a capability rotation yields a different slotRef even when credential_id is unchanged. The ambiguity above cannot arise.
• Total — every slot gets one, including ImplicitLocal and Named, so the feed is not restricted to vault-backed lanes.
• Leaks nothing — it is not derived from the capability, and it is not a handle. The wire policy banning handles is satisfied without inventing a second identity space.
• The key space stays owned here. Producers hold a token they cannot interpret, which means a future change to SlotKey does not become a breaking change for every producer.

The cost is one round trip of discovery: a producer must read a snapshot before it can attribute a fact. That seems correct rather than unfortunate — a producer that has never seen this module's view has no business asserting facts about its slots.

Obstacle 2 — fencing

The ruling states the incarnation token does not cover a second writer's door. Sharper, from the code: incarnation is the wrong token for this, because it does not move on the event that matters.

// crates/quota-core/src/store.rs:277  (reconcile_batch)
self.slots.retain(|key, _| {
    let Some(active) = authoritative.by_provider.get(key.provider.as_str()) else { return true };
    active.contains(&key.handle)
});

Slots are retained by handle membership. Incarnation advances on handle lifecycle — a handle disappearing and reappearing. An account swap behind a stable handle changes nothing about the key or the incarnation, which is exactly what SlotKey's own doc comment says:

The account label is not part of the key because a credential can change accounts without changing its handle.

So a fact observed before an account swap and delivered after it would pass an incarnation check, because the incarnation never moved. publish_if_current is a compare-and-swap over this module's own attempt lifecycle (incarnation, attempt_sequence); an external fact holds no token in that space and adding one would not help.

What the module actually uses for account change is observations_differ plus the label_in_flux flag — an assertion about identity, not a lifecycle counter.

Proposal: facts carry an identity assertion, and are dropped rather than merged when it does not match.

fact.observedIdentity = <the account/credential identity the producer believes it observed>

Accept the fact only if that assertion matches the slot's current observation. Three consequences worth stating explicitly, because two of them are refusals:

1. Mismatch drops the fact. It does not merge, does not queue, does not become "fresher". A fact about a different account is not stale data, it is data about something else.
2. A fact arriving while label_in_flux is set must also be dropped, not queued. This is the interaction the ruling flagged: the gate withholds identity precisely when identity is uncertain, so during flux there is nothing to match against. Queuing such facts for later validation is the defect — it delivers a pre-swap observation after the swap, with a delivery timestamp that makes it look newer.
3. A producer that cannot assert identity cannot contribute. Not a limitation to work around; it is the fail-closed condition. An unattributable fact is indistinguishable from a fact about the wrong account.

Ordering

The ruling's sequence holds — axis table, then contribute-only facts, then keying and fencing settled before any producer emits. I would add one item ahead of the first: the slotRef publication is a wire addition and should land and be observed on a real deployment before any producer depends on it, because a producer built against an unpublished field cannot be tested against anything.

One thing I am explicitly not proposing: no relaxation of the C1 gate to make the feed work during flux. The gate withholding labels while identity is uncertain is the property that makes the feed safe to accept at all — a feed that works during flux is a feed that can attribute one account's readings to another.

[qta-alfonso]

Both obstacle readings verified at source before I answer — the analysis is right on both, and the slotRef proposal is the correct shape for obstacle 1. But the two fixes do not compose, and that is the thing worth saying before anyone builds either.

Obstacle 1 — confirmed, and the proposal is right

CredentialHandle's doc comment says exactly what you quoted, and equality is derived over the whole variant including capability. So a rotation with a stable credential_id genuinely produces two distinct SlotKeys that a credential_id-keyed fact cannot separate. Your five-handle rotation on 2026-08-25 is the real instance.

ImplicitLocal and Named carrying no cross-process identifier is the other half, and it is the larger one on most hosts: a credential_id join would address only the vault-backed subset while looking total.

An opaque module-minted reference is the right answer, and your last argument is the one I would lead with: producers holding a token they cannot interpret means a future change to SlotKey is not a breaking change for every producer. That is worth more than the uniqueness property.

Obstacle 2 — confirmed, and it defeats the obstacle-1 fix

You are right that incarnation does not move on an account swap. Narrower, from the assignment site:

// store.rs:290  insert_missing
if self.slots.contains_key(&key) { continue; }   // <- existing key: no new incarnation
let incarnation = Incarnation::from_counter(self.next_incarnation);

Incarnation is minted only when a SlotKey is first created. An account swap behind a stable handle keeps the key, so the branch short-circuits and no new incarnation is issued.

Which means a slotRef minted per-slot inherits that property. If slotRef identifies the slot, and the slot survives an account swap unchanged, then a fact observed before the swap and delivered after it carries a slotRef that still matches. The routing token cannot also be the fence, and the two obstacles were stated separately in a way that makes them look independently closable.

What the fence has to be

You already named it: this module does not use a lifecycle counter for account change, it uses an assertion about identity. observations_differ is the single producer, and its own comment says why:

the record version ... identifies the served record and always advances when the record is replaced

So the honest shape is two tokens answering two questions:

slotRef        which slot is this fact about        stable across the slot's life
identityRef    which account was serving when observed   moves on account change

A feed fact is admissible only if BOTH still match at delivery. slotRef alone routes a stale fact to the right slot and the wrong account, which is the failure the C1 gate exists to prevent — arriving through a door the gate does not watch.

I would derive identityRef from whatever observations_differ compares rather than inventing a third thing, so that a feed fact and a poll attempt cannot disagree about whether the account changed. One producer, as that function's comment already insists.

What I am not committing to

The wire addition is real and I would not add either field before there is a producer that would emit facts, because an optional field nobody writes is the produced-but-unread shape this thread has already rejected once. The design is settled enough to build against; it is not settled enough to ship a field for.

Nothing here blocks you: both tokens are mine to mint when a producer exists.

[iceteaSA]

Consumer-side findings from reading the live header feed

I built an observe-only shadow reader against the live quota-header feed today and probed the producer on two points. Three findings change what a feed-consuming design in insula can assume. All of this is from the live feed and from producer-side source confirmation, not from the spec.

1. The feed is two sources in one envelope, and the split is permanent

The producer captured all 12 response headers from a live API call: only unified 5h and 7d rate-limit headers exist on the OAuth lane. Their WINDOW_KEYS is hardcoded to those two. There are no scoped or per-model headers on the wire at all.

So every scoped window and every extraUsage value in that feed arrived there by polling the same usage endpoint insula polls. Confirmed on my own wire: the feed's scoped Fable window read 62 while my own extraRateWindows read 62.0 for the same window at the same instant.

The consequence for any agreement or cross-check machinery: scoring those fields means confirming our own polling output. An accumulated agreement record built on them is circular, and it is circular in exactly the direction that would look like validation.

This is structural rather than a current limitation — worth encoding as such if feed facts ever enter the model.

2. Provenance is not determinable on the current schema, by any consumer-side rule

I tried two discriminators and both are unsound:

• Timestamp inference (checkedAt == observed_at_ms → header-derived). Wrong: observed_at_ms is the top-level snapshot timestamp while each window carries its own checkedAt set on a separate path. The ~16s correlation I measured is incidental. This rule would have refused everything.
• Field name (five_hour/seven_day → header-derived). Also wrong: the producer's snapshot merge is a spread, so when a response arrives without a rate-limit header, the previous poll-derived window survives the merge and continues to occupy the header field name, still stamped as header-sourced at the top level.

Both were proxies for a fact the envelope does not carry. The honest statement is that no consumer can establish per-field provenance on the current schema.

The producer is adding explicit per-field provenance tags in a schema bump and has committed to publishing the shape before it ships. Until then, a consumer that joins feed facts cannot distinguish an independent observation from its own polling echoed back.

My shadow reader keeps running but stamps every row prov=UNSOUND_V2 so the caveat travels with the datum rather than in a note beside it. Divergence remains informative — two readings that disagree cannot both be the same source — but agreement does not.

3. Scale is surface-specific, and the distinction is easy to lose

• Raw wire headers are 0-1 floats (anthropic-ratelimit-unified-5h-utilization: 0.45).
• The feed publishes them already normalized, Math.round(utilization * 100), clamped 0-100.

I was briefed that "headers are 0-1 floats needing a 100x correction" and read the live feed as 9/57/62 against my own 10.0/58.0/62.0. A consumer that applied the documented correction to the feed would have been 100x high on every window, with the error looking like a plausible reading rather than a scale fault.

If insula ever consumes this, the normalization belongs behind an assertion that refuses on a suspected scale mismatch rather than auto-correcting. A silent correction applied to the wrong surface produces exactly the wrong-and-fresh outcome the axis ruling on this issue warns about.

4. Confirmations relevant to the fencing proposal above

• Reset epochs align to the second between feed and polling on all three windows, so the join key itself is sound — it comes from shared upstream truth rather than from our arithmetic agreeing.
• configured_account_count is published, and counts accounts with live OAuth authentication present rather than structural storage presence. That satisfies the fail-closed condition I described earlier in this thread: a consumer can distinguish "one account, complete" from "one account, others idle".
• Entries are republished only on a successful response, so an idle account's record ages in place. An old snapshot timestamp is a stale reading, not a live low-utilization one. My reader abstains past a staleness horizon after a fixture showed a 1h-old entry scoring a 49-point divergence that looked entirely plausible.

Why this is on this issue rather than a new one

It bears directly on the axis ruling: header facts and polling facts are distinct measurement axes, and the practical obstacle to keeping them distinct is that the current envelope does not let a consumer tell which axis a given field came from. That is a precondition for any of the per-window contribution work discussed here, so it seemed better as an update than as a separate thread.

No action requested. Happy to test against the new schema when the shape is published.