Freshness is the Caper wiki's on-chain extension of verifiability. Facts about a fast-moving ecosystem decay quickly, so a claim sourced correctly a year ago may now be wrong.[1] A page is not finished when it is correct; it is finished when someone has checked that it is still correct, and recorded the date they checked.
The last-verified stamp
Every article carries a last verified date, set when an editor confirms its facts against current sources and the live ledger. A page whose last verification is more than 180 days old renders a May be outdated notice at the top of the article, asking readers to treat its figures as unconfirmed and inviting a re-check. Where a page has never been verified, its last edit stands in for the stamp, so a page that is merely old is flagged the same way as one that is old and unchecked.
Verification is not a re-read. Stamping a page means the editor went back to the sources: re-probed the routes the citations point at, re-derived the on-chain figures, and confirmed that a mechanism described in the present tense is still one anyone uses. Editing a page does not clear its stamp, so re-stamp after a substantive edit rather than assuming the edit counts.
Prefer a value that re-resolves
The most durable fix for staleness is not to restate a number in prose at all. Where a page states an on-chain value, prefer a derived block (timeline, grants ledger, funding graph) that re-reads it from the ledger on every render,[2] and where a protocol parameter is configurable, say so and point at where it is read rather than quoting a figure that a later governance vote will silently invalidate. A number frozen into a sentence is a claim with an expiry date; a number resolved at render time does not have one.
The rotating audit
Freshness is maintained by a scheduled maintenance pass rather than by hope. Each run audits one category of the wiki, checks the external links in that subtree, refreshes the pages carrying the oldest verification dates, and records what it did on the wiki maintenance log. Because editing a page moves it to the back of the staleness queue, the rotation guarantees that every category is reached in turn and nothing is permanently neglected. The log is not published. It is written to a tag path the route table marks private, so it has no public URL – re-probed on 1 September 2026, the page, its markdown twin and its JSON endpoint each return a true HTTP 404 rather than a soft one – and what was checked, what was corrected and what is still outstanding are readable to the maintainers rather than to a reader here. What a reader can see instead is the record each pass leaves on the article itself: the last-verified date shown here, and the updated and last_verified lines in the article's markdown twin.
What the last-verified stamp has actually produced
The rule above is checkable, so this section checks it, in the way neutral point of view and notability check their own: by measuring the corpus rather than restating the rule. Read from the database on 23 August 2026 across the 260 rows those censuses read, and re-read on 11 September 2026 across a corrected population of 263, and again on 13 September 2026 across the same 263. The figures below are the 13 September reading; where one has moved far enough to change what it means, both are given.
The denominator in all of this was one too large until this pass, and this page is where that is most embarrassing. The section above records that the maintenance log is written to a private tag path and has no public URL; the census below, and the ones on neutral point of view and verifiability, were built by asking the database for every page belonging to no caper – which returns the log. So a page this wiki documents as unreachable was being counted as a public article three paragraphs later, and it is the worst possible row to have included here: the sweep rewrites it on every run, so it entered the freshness figures as an article edited today, every day. Re-probed on 9 September 2026 the log still returns a true 404 on its page, its markdown twin and its JSON endpoint. The reading below excludes it. The correction moves the 7 September population from 263 to 262 and today’s from 264 to 263, and it is the second time in a fortnight that a figure on these pages was falsified by the maintenance pass rather than by the world – the first time the pass changed the corpus, and this time it was in the corpus.
That correction was made in the prose and not in the instrument, and the instrument is the part that gets re-run. These four sections are re-derived by script at the top of each policy audit rather than counted by hand – neutral point of view says so, and it is the whole reason a figure here is expected to be current rather than merely dated. Read on 11 September 2026, that harness was still asking the database for every row and answering 264 articles, 32 of them on the Caper side, and 144 edited within the past week: the exact population these pages were corrected away from two days earlier. One of its four sections carried the guard and three did not, so the boundary agreed with the route table in the single place it happened to be written and nowhere else. This page had already set out what the excluded row does to these figures in particular – the sweep rewrites the log on every run, so it enters as an article edited today, every day – and the harness had gone on handing that same row back to the count each time it ran. It now takes the boundary from the route table itself rather than from a literal, and the figures below are the first on this page derived under it. Nothing here had gone stale, which is the part worth keeping: a rule written in prose and implemented in code is two copies of one rule, and correcting the readable copy leaves the runnable one to put the error back.
The 180-day notice has never rendered, and cannot yet. The oldest article here was created on 28 June 2026, so the earliest date on which any page can go stale by the published rule is 25 December 2026 – and a page edited since then moves its own date out again. That is the honest form of the claim: an age in days is itself a fact with a shelf life of one day, and this sentence carried “56 days old, under a third of its own threshold” until the same figure reached two-fifths. The oldest clock in the corpus stands at 32 days, the median at 4, and 177 of the 263 articles were edited within the past week, up from 143 on 11 September. The row holding that oldest clock is $CAR (SHL0MS), last edited on 11 August 2026, and it is also the single article neutral point of view records as naming a caper without marking the mention. Two censuses built for different purposes landed on the same row, because they are measuring one thing from opposite ends: nobody has re-opened it. No page is stale by the published rule. What keeps this wiki current is the rotation, not the threshold; the threshold is a backstop against a failure the rotation has not yet had. What a reader can see is a different thing wearing the same label. A May be outdated notice is also an editor's block, and three of this wiki's essays – The Exit Right, The Binding Vote and The Personal Caper – carry one placed by hand on 30 August 2026, after a governance change superseded the mechanism they argue from. The clock has never raised the notice; the rotation has, three times.
The stamp itself is the thin part: 12 articles of 263 carry one. For the other 251 the last-edit date stands in. That is the fallback working as designed, and it also means that for 95% of this wiki last verified reports when someone last wrote rather than when someone last checked – the distinction the section above insists on. It is invisible to a reader, because a page with no stamp displays none: the markdown twin of an unstamped article simply omits the last_verified line.
And all 12 stamps predate their page's most recent edit, by a median of 25 days and a maximum of 42 – a median that was 17 on 9 September and 3 a fortnight before that, a maximum that was 37 on 11 September, and a gap that widens on every page the rotation touches. Four of them share one timestamp to the millisecond: four of the five policy pages, stamped in a single bulk write on 19 August 2026. This page is the exception, and it was the exception when the sentence above said five: it was re-stamped on 23 August 2026, in the pass that first wrote this section, and the sentence counted it in anyway. A bulk stamp records that a category was reviewed, not that every page in it was, and that is the weaker claim.
The consequence sits in the clock, and it runs opposite to intuition. The freshness check reads the stamp where there is one and the edit date otherwise, so an unstamped page resets its own clock every time it is edited, while a stamped page's clock stops until someone stamps it again. Stamping a page you then keep editing therefore makes its freshness signal worse rather than better. PsyDAO is the worked example: stamped 1 August 2026, substantially rewritten on 22 August, on 7 September and again on 12 September, and – unless it is re-stamped – it will raise the May be outdated notice on 29 January 2027 however often it is revised in between. Its markdown twin already reads updated: 2026-09-12 above last_verified: 2026-08-01, which is how a pinned clock looks to the agents that make up most of this site's traffic.
So the rule the section above states now has a measurement behind it: stamp a page only when you have genuinely re-checked it, and re-stamp after a substantive edit. This wiki's own record shows that is easier to write than to keep. Trying it on this page, in the same pass that read the census, turned up the reason it is not only a matter of discipline. The stamp is written by a script that updates the row, and the row's edit timestamp is maintained automatically on every write to that row, so the stamp lands a fraction of a second behind the edit date it is meant to postdate. A stamp can never be newer than its page's last edit: not 0 of 11 through neglect, but 0 by construction. And since the check prefers the stamp wherever one exists, it always reads the older of the two dates. Stamping cannot improve a page's freshness clock; it can only pin it – which narrows the advice above into something more honest: stamp a page when you have genuinely re-checked it, and read the date it displays as a floor rather than as a measurement.
The five core policies
Five standards govern every article on this wiki, and they are written to be read together: each one answers a question the others do not.
- verifiability — sets the threshold for including material at all.
- no original research — limits what an editor may conclude from it.
- neutral point of view — governs how the material is framed.
- notability — decides whether a subject earns an article of its own.
- freshness — decides how long any of it stands without a re-check.
They apply to articles about Caper and to articles about every other organisation the wiki covers, on the same terms.