CurveSpotter

Edition · data through

Corrections register

Corrections on record.

Every correction to this site is recorded here. Entries are appended with a timestamp and never removed.

  1. Snapshot timestamps named the run, not the fetch LATEST ENTRY
    What was wrong
    The timestamp shown as a snapshot's as-of time is captured when the collection run begins and serves as that run's identifier. A full run performs Apple lookups sequentially — two hours and seven minutes when this was first written, four hours and thirty-eight minutes now. The displayed time therefore did not state when that app was actually fetched and could differ from the measurement by approximately two hours.
    Magnitude
    Up to approximately four and a half hours between the displayed run timestamp and the app's actual fetch. A run took two hours and seven minutes when this was first written; the archive has since grown and a full night now takes four hours and thirty-eight minutes, so the gap widened with it. The error changes the true length of a nominal 24-hour comparison by as much as roughly 19%; it does not change either endpoint's stored rating count. Historical rows cannot be given a truthful per-fetch time after the fact and remain NULL.
    What changed
    Collection records fetched_at when each Apple lookup completes, separately from captured_at, which remains the run identifier used by existing joins and editions. Where a night measured one app more than once, the published observation is the one with the highest count — see the entry on within-run observations — and the per-fetch time breaks ties between equal counts. Published timestamps still cite the run, not the fetch, and we are saying so rather than implying otherwise: rows recorded before this column existed have no per-fetch time and never will, so a display mixing the two would present a precision the older half of the archive cannot support. No historical timestamp will be invented to fill the gap.
    Scope
    Every snapshot timestamp published from the site's launch onward. The stored rating counts and the identity of each collection run are unaffected.
    Detected
    Internal durability review, tracing the two-hour tracking loop from each Apple response back to the timestamp stored with its snapshot.

    The timestamp already attached to each snapshot answered one real question: which collection run produced this row. It did not answer the question the site placed in front of readers: when Apple returned the measurement for this app. Those two times are close for the first lookup in a run and can be more than two hours apart for the last.

    That distinction belongs in the data before it belongs in the interface. New rows therefore keep the existing run identifier and add the actual fetch-completion time. Old rows remain unchanged, because reconstructing a plausible time from queue order would replace a known absence with a fabricated precision.

    An earlier draft of this entry held itself back “until the display moves to the new field”. That plan is withdrawn, and saying so is part of the correction: rows recorded before the new column existed have no per-fetch time and never will, so a display mixing real fetch times with run times would present a precision the older half of the archive cannot support. Published timestamps therefore continue to cite the run — stated here plainly rather than implied — and the per-fetch time does its work where precision is real: when a night measures one app more than once, it breaks ties between equal counts.

    CS-COR-2026-0818-002
  2. When one night measured an app several times, we published the last count instead of the highest
    What was wrong
    A single night can measure one app several times — the chart sweep, the discovery stage and the nightly tracking pass each look apps up independently, and every observation is kept. Where a night held more than one, we published the one observed LAST. Apple's store API is served from edge caches, so a later request can return an older count than an earlier one did. Measured across the whole archive on 2026-08-17: 483 app-nights where the count we published sat below another count the same night had already observed, the largest by 332 ratings.
    Magnitude
    On the most recent night, 1,498 apps were measured more than once and 43 of them would publish a different number under the two readings, shifting by 60 ratings on average. The largest single shift is 2,348 ratings, on an app with 1.3 million — a 0.18% cache skew that is large in absolute terms only because the app is. The five open calls are unaffected today — all five were measured two or three times last night and both readings return the identical count for each. The two largest calls carry within-run spreads of 66 and 69 ratings on other nights, against bars of 3,428 and 1,664, so this could have decided a verdict rather than merely a listing.
    What changed
    Within a single night, the published number is now the highest count that night observed, not the last one it happened to receive. A rating count does not fall, so each observation is a floor on the app's true count, and a cached answer arriving late cannot unmake what an earlier request already established. Our criteria ask whether a count REACHES a bar — a night that saw 1,660 has established the app reached 1,660, whatever a stale cache said afterwards. The rule is applied identically everywhere a number is read, including the resolution path, and the resolver now prints the range behind any count it proposes so the person signing a verdict sees what the night actually observed.
    Scope
    Every published rating count, growth rate and ranking derived from a night that measured the same app more than once, from the archive's start until this correction. No call has resolved, so no verdict was decided under the old reading.
    Detected
    Internal review on 2026-08-17, checking the archive for cases where the published choice disagreed with the data around it.

    Nothing was re-measured. Every number involved was already in the archive, recorded the night it was observed and never altered — this changes which of several existing observations we read, not what was collected. The snapshots that produced the old figures are still there.

    The criteria that decide the five open calls are untouched. They were signed before the calls opened and they stay exactly as signed; what changed is an instrument question underneath them — given that one night produced several readings, which one is the night’s number. Answering it wrongly at a resolution would have been the worst possible moment to discover the question existed.

    We are publishing this while it is still hypothetical. On the most recent night the old and new readings agree for every open call, so nothing about the current standings moves. That is precisely why it is the right time: a measurement rule corrected before it changes an outcome is a correction, and the same rule corrected afterwards would be an excuse.

    CS-COR-2026-0818-001
  3. The methodology page stated the inverse of the boundary rule the criteria define
    What was wrong
    The page carried the since-corrected sentence that boundary cases are recorded as MISS. The signed criteria read 'rating count reaches ≥2.0× baseline' — and ≥ includes the bar, so a count landing exactly on a bar clears it. The sentence instructed the opposite of the criteria it sat directly beneath. The same inverse rule was found in five internal operating documents, including the resolution-day runbook that would have guided the first verdicts.
    Magnitude
    No resolution has occurred, so no verdict was decided under the wrong sentence. The error was in the stricter direction: a reader applying it would have expected a harder bar than the one that binds. It stops being hypothetical arithmetic at the first resolution — one open call's D+42 bar is exactly 3.0× its baseline of 5, which is 15, a number a small app can land on precisely.
    What changed
    The methodology page now states the rule the criteria define: the bars are inclusive, a count exactly on a bar clears it, and a miss is finishing below the bar or satisfying only one half of the D+21 condition. Every internal document carrying the inverse sentence was corrected, and an automated check now scans every document and page source for the inverse phrasing so the sentence cannot quietly return. The criteria themselves did not change — the prose that contradicted them did.
    Scope
    /methodology, from its first publication until this correction. No call page, resolution, ranking or velocity figure was affected.
    Detected
    Internal cross-review on 2026-08-17, while verifying a reviewer's claim that the boundary question was already settled — checking the claimed answer against the signed criteria showed the two disagreed.

    A pre-registered ledger is only worth the precision of the rules it registers. The criteria that decide every open call were signed before the calls opened, and they are inclusive: ≥ means a count that lands exactly on a bar has reached it.

    The methodology page said otherwise. Whoever read it was told that landing exactly on the bar counts as a miss — a stricter rule than the one that actually binds, stated in the sentence directly under the criteria text it contradicted. Had the first resolutions arrived with that sentence still standing, a verdict of HIT on an exact bar would have looked, to any careful reader, like the rule bent at the moment it mattered. That reading would have been wrong, but it would have been our fault, not the reader’s.

    The criteria did not move. The prose that contradicted them did. The five open calls resolve under criteria v0 exactly as signed, and the correction is recorded here rather than made quietly because editing a public claim about the rules is itself an event in the ledger’s history.

    CS-COR-2026-0817-001
  4. The edition timestamp claimed data the site did not have
    What was wrong
    The site-wide dateline named 2026-08-14T00:42:42Z as the time its data reached through. That run was a targeted collection of 14 watchlist apps, run to close a gap where an app with an open call had missed a night. It was not a measurement of the tracked population. The figures on 96% of published surfaces had in fact been measured through 2026-08-13T18:00:04.074Z, six hours and forty-three minutes earlier than the dateline above them claimed. The site's own about page states that an edition's data reaches through the timestamp it names; for those hours that sentence was not true of this site.
    Magnitude
    Six hours and forty-three minutes of overstated freshness. No published value was wrong. Every rate, count, percentile and rating total was correct as measured, and every figure carried a correct interval of its own on the page that owned it. What was wrong was the time the site attached to them collectively.
    What changed
    The edition timestamp is no longer taken from the most recent observation anywhere in the data. It now comes only from a collection that measured the whole tracked population and finished — a targeted or interrupted run records its measurements but does not advance the edition. Apps measured more recently than the edition, such as the five with open calls, show their own later timestamp on their own pages, so the dateline now understates freshness for those apps rather than overstating it for everyone else. Separately, the niche index attached one timestamp to each row, computed as the newest observation among the niche's members, which stamped the call apps' 00:42 time onto three other apps' rates. Each figure there now carries the time it was itself measured, and a median that summarizes rows measured at different times says so.
    Scope
    Every page carrying the edition dateline, from the collection run at 2026-08-14T00:42:42Z until this correction the same day. 124 of 129 app pages, 115 of 120 rankings rows, all five home movers rows and three niche index rows were affected.
    Detected
    Internal review, tracing published figures back to the data they came from. The same review confirmed the values themselves.

    This is the second correction on this register concerning a timestamp rather than a number, and the two share a mechanism. In both cases a quantity was derived by taking the newest value available and presenting it as though it described everything alongside it. A maximum has no concept of coverage: it reports that something was observed at a time, not that everything was.

    The distinction matters here more than it would elsewhere, because what this site offers is not the rating counts — anyone can read those from the App Store — but a claim about when they were measured and against what they are being compared. A figure whose timestamp is wrong is not a slightly stale figure. It is a figure that cannot be checked, because the reader who tries to reproduce it will look in the wrong place.

    The targeted collection that exposed this was itself correct and was run deliberately: an app with an open call had gone a night without being measured, and the ledger resolves against that app on 2026-09-01. Measuring it immediately was the right response. The defect was not that the run happened but that the site treated any completed collection as though it had been a complete one.

    CS-COR-2026-0814-001
  5. Two calls published with an open date in the future
    What was wrong
    Both entries were drafted expecting publication on 2026-08-14 and carried calledAt 2026-08-14T00:00:00Z. They were signed and published on 2026-08-13, so for several hours each page stated an open date that had not yet arrived, in its header, its facts table and its citation block.
    Magnitude
    The open date was one day ahead of publication. The baselines the calls are measured against were unaffected: both cite the 2026-08-12T18:00:01Z snapshot, and the rating counts (832 and 1,714) were correct as published.
    What changed
    Both entries now open on 2026-08-13, the day they were published, and their resolution dates moved with them — D+21 from 2026-09-04 to 2026-09-03, D+42 from 2026-09-25 to 2026-09-24. The methodology now states the convention the entries were written against: open times are recorded at day granularity, the baseline carries the exact snapshot timestamp it came from, and no entry opens later than the day it publishes.
    Scope
    /calls/ziggy and /calls/scrollfit, from their publication on 2026-08-13 until this correction the same day.
    Detected
    Internal pre-announcement review, before the site had been announced to anyone.

    The dates a call is opened and resolved are the mechanism by which this ledger can be checked. A reader who cannot trust the open date cannot trust anything derived from it, including the claim this site exists to make — that the call preceded the outcome.

    Editing a published entry is itself a change to the record, which is why it is recorded here rather than made quietly. Nothing else in either entry was altered: the evidence, the baselines, the mechanism quotes and the stated risks are as they were signed.

    CS-COR-2026-0813-002
  6. Growth rates published from sub-daily observation windows
    What was wrong
    Published growth rates were computed from the two most recent adjacent snapshots with no minimum observation window. Collection ran twice on 2026-08-12, so 57 of 60 ranked rows normalised a 6.85-hour observation to a per-day rate.
    Magnitude
    Libre by Abbott published +1,098.1/day against a windowed figure of +360.2/day (3.05×). Brainrot: Screen Time Control published +603.4/day against +183.5/day (3.29×). Welmi published +336.8/day against +121.6/day (2.77×).
    What changed
    Published rates now come from a window of at least 20 hours — the floor the project's own scorer already applied internally and the site's data path was bypassing. Where no qualifying window exists, no rate is published at all.
    Scope
    /rankings, every /niches/* page, and the growth figure on every /apps/* page, from the site's launch until 2026-08-13.
    Detected
    Internal review, before the site had been announced to anyone.

    App Store rating counts arrive in batches. A sub-daily window does not measure a rate; it measures where a batch boundary fell. Libre by Abbott’s rating count was unchanged for the 17 hours before the affected window, then moved 313 inside 6.85 hours. Normalised to a day, that boundary published as +1,098.1/day where a 20-hour window measures +360.2/day.

    The Worker scorer already enforced a 20-hour minimum observation window internally. The site’s data path read the two most recent adjacent snapshots directly and bypassed that floor. Published rates now pass through the same floor, and rows without a qualifying window carry no rate.

    CS-COR-2026-0813-001