Back

Wallet Intelligence report review

P14-L05 · P14 · P14-M02

Assess wallet evidence and attribution confidence limits

HISTORICAL · needs_review

Prerequisites: P14-L04

Learning objectives

  • Assess wallet evidence and attribution confidence limits
  • Read aggregate wallet fields without inventing raw transactions, funding paths or identity.

Explanation

A Wallet Intelligence aggregate is a saved summary, not a raw interaction graph. Read each count within its stored coverage boundary and preserve unknown provenance. An address is an object locator, not a human identity.

Explanation

The accepted Solana wallet is mpa4abUkjQoAvPzREkh5Mo75hZhPFQ2FSH6w7dWKuQ5. The table public.zecoin_wallet_intelligence_snapshots is located by wallet_address, network and observed_at. observed_at=2026-09-06T02:58:05.641Z; created_at=2026-09-06T02:58:05.667Z. The 26 ms separation is product persistence timing, not an independent provider measurement.

The row stores asset_count=100, transaction_count=25, transfer_count=0, counterparty_count=0 and signal_codes=[high_single_asset_concentration]. total_usd_value is null and must remain UNKNOWN, not zero. The fields describe the stored product aggregate. They do not expose transaction IDs, funding edges, counterparties, clustering inputs or the coverage window. In particular, a zero count in this bounded snapshot cannot prove absence of such activity over the wallet lifetime.

The table does not retain raw provider response, per-field provider timestamp or human/funding/cluster owner attribution. The concentration code is a product classification whose raw basis cannot be independently rederived from this row alone. Keep OBSERVED for saved aggregate fields, UNKNOWN for unavailable provider coverage, and INSUFFICIENT EVIDENCE for insider, human or same-controller conclusions. No wallet signing, account access or current provider call is needed to review this record.

Historical example

A report can state “The accepted aggregate stores 25 transactions and the concentration code.” It cannot state “These 25 transactions fund an insider cluster” because no funding edges, human identity or cluster basis are supplied. It also cannot link this unrelated wallet to the WIF object from L02 merely because both appear in P14.

What the evidence proves

OBSERVED is bounded to the specified saved artifact or explicitly fictional fixture. INFERRED claims name their inputs and assumptions. Aggregate product snapshot only; no raw provider response, per-field provider time, funding-owner, cluster-owner or human-identity attribution.

What the evidence does not prove

UNKNOWN fields remain absent. INSUFFICIENT EVIDENCE does not prove the opposite. No unsupported human attribution, guaranteed safety/profit, financial recommendation or executable transaction follows.

Common mistakes

Promoting UI or aggregate fields into raw provider records; substituting dates across sources; inventing hidden identity or links; treating a timestamp or commercial badge as proof.

Practical exercise

Write a record header and three evidence-state rows for total value, transfer count and insider status. Explain which raw records would be needed for a future bounded funding claim, without collecting them or adding imagined counterparties.

Show worked correction

Header: exact Solana wallet and composite locator; product observed_at and database created_at separated. Total value UNKNOWN because null. Transfer count OBSERVED as aggregate zero, with coverage window UNKNOWN and no lifetime absence claim. Insider status INSUFFICIENT EVIDENCE. A future funding claim would need saved exact transaction/asset identities, direction, timestamps and provider/retrieval provenance; none are manufactured here. The accepted row remains a useful bounded aggregate despite those limits.

Visual specifications

A wallet aggregate panel beside an empty interaction graph. Show counts and concentration code in the panel; mark funding edges, counterparties and human identity unavailable. Draw no invented cluster lines. Contrast observed_at with created_at and provider time UNKNOWN.

SPECIFICATION_ONLY — final visual production is not part of this content run.

Checklist

  • Name the exact artifact and identity boundary.
  • Preserve source/time/dataStatus for each claim.
  • Keep OBSERVED, INFERRED, UNKNOWN and INSUFFICIENT EVIDENCE distinct.
  • Preserve limitations without private data or current substitutes.

Summary

  • Artifact integrity is distinct from factual completeness.
  • Origin and timestamp precision survive reuse.
  • A bounded conclusion must survive its unknowns.

Next lesson

P14-L06

Tools

Offline evidence-reading exercise only. No provider refresh, private account access, real-money exercise, wallet signing, entitlement change or runtime output generation.

Sources & claim boundaries

Evidence classifications

HISTORICAL — Aggregate product snapshot only; no raw provider response, per-field provider time, funding-owner, cluster-owner or human-identity attribution.

Observation date

2026-09-06T02:58:05.641Z (specified product/UI time; not universal provider time)

Review status

needs_review

Visual specifications

P14-L05-V01

SPECIFICATION_ONLY · HISTORICAL

Assess wallet evidence and attribution confidence limits

Aggregate product snapshot only; no raw provider response, per-field provider time, funding-owner, cluster-owner or human-identity attribution.

A wallet aggregate panel beside an empty interaction graph. Show counts and concentration code in the panel; mark funding edges, counterparties and human identity unavailable. Draw no invented cluster lines. Contrast observed_at with created_at and provider time UNKNOWN.

A wallet aggregate panel beside an empty interaction graph. Show counts and concentration code in the panel; mark funding edges, counterparties and human identity unavailable. Draw no invented cluster lines. Contrast observed_at with created_at and provider time UNKNOWN.

Stack each claim/source/time/boundary card at 390 px; keep full IDs readable and wide tables inside local scrollers. Provide the complete text equivalent.

Prose may use RTL; identifiers, exact times and decimal arithmetic remain LTR. Preserve relationship direction.

P14-L05-SOLANA-WALLET-20260906T025805641Z-v1

Sources & claim boundaries

WALLET · CONTROLLER_VERIFIED_PRODUCTION_TRANSCRIPTION

Controller-verified bounded historical Wallet aggregate

Supported claim
Specific example and exercise fields/claim boundaries in this lesson
Verification boundary
Aggregate product snapshot only; no raw provider response, per-field provider time, funding-owner, cluster-owner or human-identity attribution.
Checked at
2026-10-02
Open primary source
https://github.com/Samizghal/zecoin/blob/5ad423a67a3c9892fd4e3b6e3464c4f40a7d1795/content/academy-2/datasets/p14-l05/dataset.json

Dataset provenance

id: P14-L05-SOLANA-WALLET-20260906T025805641Z-v1

dataStatus: HISTORICAL

observedAt: 2026-09-06T02:58:05.641Z

source: content/academy-2/datasets/p14-l05/dataset.json

scope: Aggregate product snapshot only; no raw provider response, per-field provider time, funding-owner, cluster-owner or human-identity attribution.

Test your reasoning

P14-L05-Q1 · How should total_usd_value=null be represented?
P14-L05-Q2 · Does counterparty_count=0 prove no lifetime counterparties?
P14-L05-Q3 · What supports calling the wallet an insider?
P14-L05-Q4 · What does created_at establish here?
P14-L05-Q5 · Can a funding graph be drawn from these counts?