Back

Discovery observation versus recommendation

P14-L03 · P14 · P14-M01

Treat discovery as an observation queue with coverage limits

HISTORICAL · needs_review

Prerequisites: P14-L02

Learning objectives

  • Treat discovery as an observation queue with coverage limits
  • Audit only visible screenshot claims while preserving missing Discovery provenance.

Explanation

Discovery is an observation queue with coverage limits. A candidate card is a prompt to inspect evidence, not a recommendation, endorsement, buy signal or prediction. Here the historical evidence is preserved UI pixels and a bounded transcription of what they display.

Explanation

The accepted screenshot zecoin-discovery-cards.jpg has SHA-256 614c13b7c9ca9ac758cd9b0dfe61addf5b323f7e7c30978dc692b9dc8bd50b60. UI01 displays XChan (XCHAN), SOLANA, source label DEX Screener and Observed 2026-09-18T16:38:21.452Z. UI02 displays Base is for Everyone (Gold) (Everyone), BASE, source label Zora and Observed 2026-09-18T16:37:01.000Z. Those are claims visibly preserved in this UI artifact. The lesson metadata time is the first displayed example; it is not a universal capture or provider time.

The capture preserves source-labelled candidate cards, network filter context and Analyze with ZECOIN buttons. The link destination is not recoverable merely because a link label or arrow is visible. A source label does not expose the provider response, sourceObservedAt, complete collection method or coverage envelope. No hidden href is inferred and no address is reconstructed. This dataset deliberately limits its identity transcription to visible candidate text/chain; canonical exact identity remains UNKNOWN.

Separate two statements: “the screenshot displays this timestamp” is OBSERVED at the UI layer; “the provider measured every field at that instant” is not established. sourceObservedAt, provider retrieval time, original href targets, full envelope and absent fields remain UNKNOWN. The provenance gaps themselves are useful findings. A checksum protects these saved bytes, not the truth of all underlying data or the existence of a complete archive.

Historical example

For UI01, the safe dossier entry is “A preserved Discovery UI card displays XChan (XCHAN), SOLANA, DEX Screener and the stated Observed timestamp.” Its recommendation claim is NOT SUPPORTED. The same reasoning applies to UI02; the provider label differs but the screenshot-only boundary does not.

What the evidence proves

OBSERVED is bounded to the specified saved artifact or explicitly fictional fixture. INFERRED claims name their inputs and assumptions. BOUNDED HISTORICAL UI ARTIFACT: only visible candidate text, chain, source label, displayed Observed and UI context. No raw provider archive or complete historical feed export.

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

Transcribe the five accepted visible categories for both examples. Write a separate UNKNOWN register and classify the sentence “Discovery recommended these two assets because the provider proved their quality.” Keep the JPEG hash and do not follow or guess any hidden link.

Show worked correction

UI01/UI02 retain visible candidate text, chains, labels, displayed Observed values and shared card context. UNKNOWN: sourceObservedAt, original hrefs, full feed envelope, complete retrieval method, provider retrieval time and canonical exact candidate identity. Recommendation, endorsement, buy signal, prediction and complete provider provenance have INSUFFICIENT EVIDENCE; the recommendation claim is NOT SUPPORTED. Repaired sentence: “The screenshot preserves two Discovery observations; their underlying completeness and suitability are not established.” No live collection is required.

Visual specifications

Two screenshot-linked observation cards and a separate missing-provenance lane. Label the time axis Displayed Observed, never provider time. Put a visible BOUNDED HISTORICAL UI ARTIFACT caption and a NOT SUPPORTED recommendation box; do not draw unseen links or IDs.

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-L04

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 — BOUNDED HISTORICAL UI ARTIFACT: only visible candidate text, chain, source label, displayed Observed and UI context. No raw provider archive or complete historical feed export.

Observation date

2026-09-18T16:38:21.452Z (specified product/UI time; not universal provider time)

Review status

needs_review

Visual specifications

P14-L03-V01

SPECIFICATION_ONLY · HISTORICAL

Treat discovery as an observation queue with coverage limits

BOUNDED HISTORICAL UI ARTIFACT: only visible candidate text, chain, source label, displayed Observed and UI context. No raw provider archive or complete historical feed export.

Two screenshot-linked observation cards and a separate missing-provenance lane. Label the time axis Displayed Observed, never provider time. Put a visible BOUNDED HISTORICAL UI ARTIFACT caption and a NOT SUPPORTED recommendation box; do not draw unseen links or IDs.

Two screenshot-linked observation cards and a separate missing-provenance lane. Label the time axis Displayed Observed, never provider time. Put a visible BOUNDED HISTORICAL UI ARTIFACT caption and a NOT SUPPORTED recommendation box; do not draw unseen links or IDs.

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-L03-DISCOVERY-UI-20260918-v1

Sources & claim boundaries

UI · PRESERVED_REAL_UI_SCREENSHOT

Accepted bounded historical Discovery UI artifact

Supported claim
Specific example and exercise fields/claim boundaries in this lesson
Verification boundary
BOUNDED HISTORICAL UI ARTIFACT: only visible candidate text, chain, source label, displayed Observed and UI context. No raw provider archive or complete historical feed export.
Checked at
2026-10-02
Open primary source
https://github.com/Samizghal/zecoin/blob/8f2bfe61821ef33b666817c856a78b6e45da0af2/content/academy-2/datasets/p14-l03/dataset.json

Dataset provenance

id: P14-L03-DISCOVERY-UI-20260918-v1

dataStatus: HISTORICAL

observedAt: 2026-09-18T16:38:21.452Z

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

scope: BOUNDED HISTORICAL UI ARTIFACT: only visible candidate text, chain, source label, displayed Observed and UI context. No raw provider archive or complete historical feed export.

Test your reasoning

P14-L03-Q1 · What is directly OBSERVED for XChan in this package?
P14-L03-Q2 · Can the visible DEX Screener arrow recover its original href?
P14-L03-Q3 · How should displayed Observed be labelled?
P14-L03-Q4 · What supports calling these cards a recommendation?
P14-L03-Q5 · What does the JPEG checksum establish?