Privasea AI (PRAI) — the revision ledger

Generated 2026-09-03T22:55:50Z from live ClickHouse queries against this estate's ledger. Point-in-time archive held for Privasea AI: 8,031 observations · 29 distinct series · 3 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-09-03 22:47:01 · every one of the 8,031 rows carries a verify_url · 29 series refreshed in the last 24h (608 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where Privasea AI's archive comes from

3 source families feed this network's ledger. Every row they wrote carries its own source, as_of and verify_url; this table is the live rollup of that. Privasea AI (the catalog name here is Privasea AI, category AI, chain binance-smart-chain, token contract 0x899357e54c2c4b014ea50a9a7bf140ba6df2ec73) publishes no first-party stats API of its own in this estate's catalog — the chain-side series held for PRAI come from this estate's own BSC readers (bsc_rpc: the on-chain total supply and the burn-address balance; bsc_deep_stats: the BSC token supply and circulating series), with CoinGecko's market series alongside. The absence of chain-counter sources below is structural — these are supply and balance reads, not counters.

Revision ledger — 0 backward revision(s) recorded for PRAI

The ledger query ran during generation and returned 0 rows for PRAI. Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions?symbol=PRAI (the same query this page ran, served live), and a restatement would appear on this page the day the detector records one. /v1/revisions?symbol=PRAI cross-check passed: the served API reports 0 row(s), matching the ledger count rendered on this page.

Why zero is the interesting answer here. The detector watches every cumulative-by-construction series — counters that cannot decrease unless upstream rewrote them (block heights, transfer counters, lifetime fees). The live intersection of that watchlist with what the daily archive holds for PRAI is empty, measured below: nothing this estate's collectors touch for PRAI is a monotone counter. The chain-side series are supply and burn-address balances — supply is excluded by name in the detector's own vocabulary (mint/burn/vesting move it legitimately, so a drop there is a real token event, not a rewrite); the market series are price-driven classes the detector excludes by name. The structural zero is therefore: the archive is fully exposed, and no held series is of the class that can expose a rewrite. Publishing an empty ledger as a live query result — instead of padding it with gauge noise — is the same retention discipline the ledger exists to sell.

What the detector watches for Privasea AI — the intersection, measured

The detector diffs every daily snapshot of every cumulative-by-construction series. Below is the live intersection of the estate detector's cumulative watchlist — imported directly from propintel/revision_ledger.py (75 declared names, so this page can never drift from the detector) — with what the daily archive holds for PRAI.

Live query result: 0 watchlist series held for PRAI. The intersection query ran during generation and returned an empty set — none of the 75 cumulative-by-construction metric families the detector watches appear in PRAI's daily archive. This is the structural zero behind the ledger count above, published as the query found it. The full series inventory PRAI's archive does hold follows, so the disjoint is checkable row by row.

Everything the daily archive holds for Privasea AI — the other side of the disjoint

26 series held for PRAI in depin_daily, all of them supply-, balance-, gauge- or price-class: none appears in the detector watchlist above. This inventory is live — it is the query result, not a curated list.

The trail that only ever moved one way — and why it is not a ledger row

PRAI's burn-address balance (onchain_burn_address_balance, read by this estate's bsc_rpc collector at the BscScan burn-holder endpoint) is the one series in the archive that only ever moved one way: 0 → 0.01000001 → 58.80000001 → 150.46670001 across the window, rendered raw below. It is not a revision-ledger candidate — supply and balance series are excluded by name in the detector's vocabulary (mint/burn move them legitimately), and the detector classifies on construction, never on measured monotonicity: a one-way run over 11 days is a trend, not a structural guarantee. The page publishes the trail so the reader sees both what the estate holds and exactly why the detector did not treat it as a counter.

Cross-source supply reconciliation — two independent pipelines, one quantity

CoinGecko's total_supply series and this estate's own BSC chain read (onchain_total_supply, via bsc_rpc) hold the same quantity from two independent pipelines. Measured live on every snapshot day both exist: 17 agreeing days, 1 divergent of 18 overlap days. CoinGecko's circulating_supply is a different quantity (the market convention: total minus locked/vesting), and the gap between it and total supply is rendered raw alongside — this estate records what upstream published, including where upstream's own two supply figures disagree with each other, and lets the reader judge.

Gauges that moved backward — deliberately NOT revisions

These series fall outside the detector's cumulative-by-construction class (NOT_TRULY_CUMULATIVE and plain gauges in propintel/revision_ledger.py): a drop there is a real market or window change, not upstream rewriting history. For PRAI the price and market-cap classes lead the table (10 backward moves each on their windows) — a price fall revalues every derived series; that is a market move, not a rewrite. Publishing them as "revisions" would be exactly the fake-metric behaviour this product exists to eliminate.

Same-timestamp conflicting values on record for PRAI: none

The task-level conflict check, run live: any (metric, timestamp) family where this estate recorded two or more different values. The query ran at generation and returned 0 groups in both depin_onchain and depin_daily — every (metric, timestamp) pair the estate holds for PRAI carries exactly one value. Zero here is the live query result, not a gap; the archive kept every write it made, and none of them disagree. (The cross-source supply reconciliation above is a cross-source comparison of two different pipelines holding the same quantity — not a same-stamp conflict — which is why it lives in its own section.)

The ledger, live — every restatement recorded estate-wide (20 deduped events)

Deduped on revision identity exactly as /v1/revisions dedupes it. This is the same feed a subscriber polls; it is rendered live from ClickHouse at generation, not copied from a snapshot. Each row is an upstream source replacing the value of a (network, metric, date) it had already published — after this estate recorded the original. The superseded value is retained, never deleted; that retention is the only reason a rewrite is detectable, and it is the part every overwriting vendor discards.

How detection works — and what it cannot see

The detector (propintel/revision_ledger.py) diffs every daily snapshot this estate holds of every cumulative-by-construction series — counters that cannot decrease unless upstream rewrote them (block heights, transaction and transfer counters, lifetime fees). A row enters default.depin_revision_ledger iff two snapshots disagree for an already-observed date; zero human judgement. Resolution rule: latest observation wins for current-state reads, the superseded value is retained, never deleted. Population gauges (provider sets, node counts, prices, capacity, rolling windows) legitimately move both ways and are deliberately excluded — a drop there is a real change, not a rewrite; the gauge table on this page is the worked example, and for PRAI it covers the moving part of the entire held inventory. Honest boundary: this catches value-history rewrites ex-post; identical-schema semantic drift with plausible values is what the hash-pinned derivation_replay layer is for. The detector's full classification is inspectable at /v1/revisions and frozen daily at /revision-ledger/REVISIONS_20260902.json.

The snapshot archive the detection runs over

PRAI's slice of depin_daily: 352 rows over 18 snapshot days (2026-08-09 → 2026-09-02), from 2 source families. Each snapshot is a same-day capture of every series the collectors touched; the detector diffs consecutive snapshots of cumulative series across this window. This is the substrate the zero above is measured over — not an assumption, a measured archive.

Estate grades for PRAI (graded 2026-08-20 13:54:15.000)

Served by /v1/network/PRAI — the same grades a paying agent receives. Scores are the engines' own 0–100 outputs, published exactly as the engines emitted them, unflattering parts included.

Verify any cell yourself — the exact commands

No account, no key, no trust required. Commands 1–2 hit this estate's public API (the same rows this page queried — every row carries source / as_of / verify_url); command 3 is the BscScan token page, the origin of every chain-side series on this page (3b is the burn-holder view the burn trail came from); command 4 is the CoinGecko origin page; command 5 is the estate's graded network row; command 6 is the frozen daily snapshot of the ledger. One polite call per endpoint, no hammering.

# 1) The served revision feed for PRAI — the same rows this page queried, live:
curl -s "https://kairossignal.com/v1/revisions?symbol=PRAI" | python3 -m json.tool
# 2) The estate-wide feed (every network, both sides of every diff):
curl -s "https://kairossignal.com/v1/revisions" | python3 -m json.tool | head -80
# 3) BscScan PRAI token page (the bsc_rpc / bsc_deep_stats origin):
curl -s -o /dev/null -w "%{http_code}\n" "https://bscscan.com/token/0x899357e54c2c4b014ea50a9a7bf140ba6df2ec73"
# 3b) The burn-holder balance endpoint (the onchain_burn_address_balance origin):
curl -s -o /dev/null -w "%{http_code}\n" "https://bscscan.com/token/0x899357e54c2c4b014ea50a9a7bf140ba6df2ec73?a=0x000000000000000000000000000000000000dead"
# 4) CoinGecko PRAI page (the market-series origin; browser-verified, bot-walled to curl):
curl -s -o /dev/null -w "%{http_code}\n" "https://www.coingecko.com/en/coins/privasea-ai"
# 5) This estate's public API row for PRAI (grades + provenance):
curl -s "https://kairossignal.com/v1/network/PRAI" | python3 -m json.tool | head -60
# 6) The public daily snapshot of the ledger (frozen copy):
curl -s -o /dev/null -w "%{http_code}\n" "https://kairossignal.com/revision-ledger/REVISIONS_20260902.json"

Method & honesty notes. All counts are queries against the live ledger at generation time, not restamped copy — this page is regenerated by gen_revision_page_prai.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. The PRAI revision count is the live result of SELECT count() FROM default.depin_revision_ledger WHERE network='PRAI'; the page refuses to ship if the served /v1/revisions?symbol=PRAI is reachable and disagrees with it (at generation the estate API was reachable and the cross-check passed). The 20 estate-wide events shown are deduped on revision identity (deterministic hash of network, metric, current_date, prior_date) exactly as the API dedupes them; detected_at is the first detection and never moves. Series absent from a section are absent, not zero. The same-stamp conflict check is the honest live answer: 0 groups in depin_onchain and 0 in depin_daily. The cross-source supply reconciliation is re-diffed from the raw trails on every regeneration — if the two pipelines ever disagree, this page will say so. Upstream probes ran serially by this generator immediately before rendering: CoinGecko PRAI page (the market-series origin; 403 here is its bot wall) HTTP 403; BscScan PRAI token page (the bsc_rpc / bsc_deep_stats origin) HTTP 403; estate /v1/revisions?symbol=PRAI HTTP 200; estate /v1/network/PRAI HTTP 000.