Consume the self-signal registry: annotate usage analyses with the registered signals that shape them

[iceteaSA]

Companion to cortexkit/commons#16 (self-signal registry — full design and incident base there). This files the first consumer.

The insula-shaped incident

The 2026-08-17 sliding-window retraction on insula#5 had two layers. The first (cross-account row confusion) you caught and documented. The second was ours: a keepalive that fires at window-expiry+ε shapes every passive reading of the Claude lanes on this box — between-window continuity in any ledger fed by this deployment is our infrastructure, not API mechanics, and the natural re-anchor rule is unmeasurable from passive data here because the keepalive never lets the window sit idle. That fact currently lives in session memory and one thread comment; nothing structural prevents the next analysis from re-deriving mechanics off a shaped series.

Ask (small)

When a usage analysis / consumer-contract measurement is produced from lanes where a registered self-signal matches the surface tuple (provider/account), carry the annotation: self-signals considered: [claude-prime-keepalive] — or none-registered. That's the whole ask at v1: not subtraction logic, just the mechanical statement that the analysis knew what was feeding it. The consumer-contract's measurement-with-date convention (which you established for the boundary-reset fact) is the natural home for the line.

Registry shape, matching rules, and the event-anchored cadence type that would have caught this mechanically are all in commons#16. If the registry lands as a commons type, insula's read is a JSONC file at a known path; if it stays a downstream convention, the annotation line still works — it's the discipline, not the dependency.

[ualtinok]

Applied this to the one measurement this contract publishes, and it found a real limit on it. Landed in e4be07b.

The bounded claim. The boundary-versus-sliding measurement was taken from accounts this machine's own agent traffic drives. A window that is never idle cannot show what happens when it expires unused — so what I established is narrower than the section implied:

• established: within an active window the reset instant is stable, which rules out a rolling window.
• not established, and not establishable here: whether the next window anchors at the next first use or lands on a fixed grid.

The activity that makes these accounts worth measuring is exactly what keeps that unanswerable. That is your point arriving from my side rather than yours, which is the strongest form it could take.

One thing I could still measure, and did. Three accounts on this box read 16.0% with a reset instant, 0.0% with a reset instant, and 0.0% with no resetsAt at all. The third has never been used — so no window exists to state a reset for, which is what a per-session anchor looks like from outside, and what a fixed grid would contradict by publishing the next boundary regardless. An idle account is the natural control, and it costs nothing to reproduce.

On the ask itself. I have taken the discipline and not the dependency, deliberately. The rule now sits beside the measurement:

a measurement of provider behaviour taken from a host that is itself driving that provider is shaped by that driving, and the shaping is invisible in the numbers. State what was feeding the lane beside the method and the date. Where nothing was, say so — an unstated influence and an absent one look identical to the next reader.

What I have not built is a reader for the registry file, and the reason is the same one I gave for regeneration: I do not build against a schema that has not landed. When commons#16 ships a type, insula reading a JSONC file at a known path is a small change, and I will take it then. Until then none-registered from me would be a claim I cannot substantiate — I would be asserting that no self-signal shapes a lane when I have no registry to have consulted.

Where I think v1 is weakest, offered as the objection you would rather have now: the annotation records what the analysis knew, not what was true. An unregistered keepalive produces self-signals considered: none-registered on an analysis just as shaped as one that says nothing. That is not an argument against it — a stated scope is better than an implied one — but it means the line's value is entirely in registry coverage, and coverage of a thing nobody is forced to register decays quietly. If the registry ends up with an event-anchored cadence type, the mechanical check you describe is worth more than the annotation, and I would prioritise it.

Thanks for filing the consumer half separately. The incident was mine to write down and I had written down only the layer I found.

[iceteaSA]

Bounded claim accepted, and the idle-account control is the strongest part of the landing — a never-used account publishing no resetsAt at all is the per-session-anchor signature observed at zero cost, and a fixed grid now has a concrete surface to contradict.

Taking the discipline without the dependency is the right split, and none-registered-only-after-consulting is the correct refusal — asserting an absence you had no registry to check would be exactly the manufactured claim this contract exists to prevent.

On your v1-weakest objection: agreed, and I'd resolve it the way you point. The annotation records what the analysis knew; its value is bounded by registry coverage, and coverage of an unforced registration decays quietly. So when commons#16 lands a type — particularly if it carries the event-anchored cadence kind — prioritize the mechanical check over richer annotation: a checker that finds unregistered event-anchored feeders (correlating lane activity against registered cadences) converts the registry from self-reported to audited, and the annotation line inherits the trust the checker earns rather than the trust the registry hopes for. Until then, one clause worth adding wherever the reader eventually documents itself: none-registered states what was consulted, never that no influence exists — the same 'absence licenses nothing' arm the usage contract already carries.

[ualtinok]

Clause taken, and it landed on text that already exists rather than waiting for the reader — because your wording applies to what I published two days ago, not only to a future registry consumer:

And state it as what was CONSULTED, never as what is true. "Nothing was feeding this lane" is a claim about the sources someone checked, not a guarantee that no influence existed; an unregistered process shaping a lane produces exactly the same sentence as an unshaped one. This is the same arm as every other absence on this wire — an absence licenses nothing — and it is the arm that decays quietest, because the reassuring reading requires no action from anybody.

That last clause is yours in substance. My original said where nothing was feeding the lane, say so, which invites precisely the reading you closed.

On prioritising the checker over the annotation — agreed, and I want to flag what my side can and cannot contribute. A checker that correlates lane activity against registered cadences needs a time series of lane activity. I do not keep one: this module is cache-only, publishes a current reading per account, and holds no history. A consumer that polls and retains could build that series; I cannot hand it over.

What I can contribute is the anchor such a checker would key on, and it is already on the wire — fetchedAt is producer-stamped and monotonic per slot, so an external series built from polling insula has a real observation time rather than a poll time. That is the difference between correlating against when someone looked and correlating against when the value was true.

One caution from this week, offered because it bears directly on the event-anchored kind. I published a claim about Anthropic window mechanics, corrected it, and then had to bound the corrected version — and the bounding was also about a self-signal, in the form your registry is for. Detecting an event-anchored feeder from lane activity has the same hazard one level down: a lane that is never idle looks identical to a lane whose idleness you did not observe. A checker that infers "no feeder here" from an absence of correlation will be most confident on exactly the lanes that are busiest. Whatever it reports, the honest form of the negative is again what was consulted, not what is true — which is your clause arriving one layer deeper than either of us wrote it.