Back

Observed inferred unknown and insufficient evidence

P14-L01 · P14 · P14-M01

Classify claims consistently across the four evidence states

ILLUSTRATIVE · needs_review

Prerequisites: P08-L08 · P09-L08

Learning objectives

  • Classify claims consistently across the four evidence states
  • Assign evidence states to individual claims instead of treating a report badge as a universal truth.

Explanation

An evidence state belongs to a claim. OBSERVED means the named artifact preserves a stated field or event within a specified measurement boundary. INFERRED means a conclusion follows from named observations plus stated assumptions. UNKNOWN means a needed value is absent. INSUFFICIENT EVIDENCE means a proposed conclusion lacks adequate support; it does not prove its opposite.

Explanation

Start by writing the claim before choosing its state. “The fictional card contains review” can be checked against the fixture. “If the flag persists unchanged, the next sample will also contain review” is a conditional inference under an explicit persistence assumption. The future sample itself remains absent. “The provider measured this at a particular instant” needs a provider record that this fixture does not contain. “A named person controls the object” needs identity evidence that an abstract label cannot supply.

Use a four-column register: claim, artifact pointer, evidence state and boundary. An inference must name both inputs and assumptions, not merely inherit the confidence of the input report. A later missing measurement is UNKNOWN even when an earlier sample exists. Unsupported attribution is INSUFFICIENT EVIDENCE even if the report looks detailed.

ILLUSTRATIVE is the data origin of these cards. OBSERVED in this exercise means visible in the fictional fixture, not observed on a real blockchain. Never promote a simulated label or a neatly formatted table into historical product evidence. A record may contain several states at once, and a review badge must remain distinct from an editorial reviewStatus of needs_review.

Historical example

SIM-ALPHA is a fictional label with no chain or address. The fixture contains displayedFlag=review; laterState and allegedOperator are null. The bounded statement is “the educational fixture contains a review flag.” Its provider coverage is UNKNOWN and its alleged human operator is not established. No capital or wallet is involved.

What the evidence proves

OBSERVED is bounded to the specified saved artifact or explicitly fictional fixture. INFERRED claims name their inputs and assumptions. Author-defined fictional cards, not provider observations or an actual ZECOIN report.

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

Classify four claims: (1) the fixture displays review; (2) the next sample will display review; (3) the provider timestamp is known; (4) the same person controls this and another object. For each, supply a pointer, assumption if relevant, and a sentence that avoids expanding the claim.

Show worked correction

(1) OBSERVED within /classificationCards/displayedFlag and the ILLUSTRATIVE boundary. (2) INFERRED only conditionally, assuming the flag persists unchanged. No evidence here establishes that assumption or the future result; without it, the future-persistence claim has INSUFFICIENT EVIDENCE and the later state is UNKNOWN. (3) UNKNOWN: observedAt and provider evidence are absent, not recoverable from the file date. (4) INSUFFICIENT EVIDENCE: no person, chain or control evidence exists. A valid register keeps all four statements separate. Do not replace null with zero or turn lack of evidence into a denial of control.

Visual specifications

Four claim cards connected to a claim register. Use distinct state labels, show SIMULATED above every card, and leave missing-time and attribution cells visibly UNKNOWN/INSUFFICIENT EVIDENCE. No confidence percentage or safety color is inferred.

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

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

ILLUSTRATIVE — Author-defined fictional cards, not provider observations or an actual ZECOIN report.

Observation date

null — ILLUSTRATIVE fixture has no historical observation timestamp.

Review status

needs_review

Visual specifications

P14-L01-V01

SPECIFICATION_ONLY · ILLUSTRATIVE

Classify claims consistently across the four evidence states

Author-defined fictional cards, not provider observations or an actual ZECOIN report.

Four claim cards connected to a claim register. Use distinct state labels, show SIMULATED above every card, and leave missing-time and attribution cells visibly UNKNOWN/INSUFFICIENT EVIDENCE. No confidence percentage or safety color is inferred.

Four claim cards connected to a claim register. Use distinct state labels, show SIMULATED above every card, and leave missing-time and attribution cells visibly UNKNOWN/INSUFFICIENT EVIDENCE. No confidence percentage or safety color is inferred.

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.

SIM-P14-EVIDENCE-WORKFLOW-v1

Sources & claim boundaries

Dataset provenance

id: SIM-P14-EVIDENCE-WORKFLOW-v1

dataStatus: ILLUSTRATIVE

observedAt: null

source: content/academy-2/labs/datasets/p14-illustrative-fixtures.json

scope: Author-defined fictional cards, not provider observations or an actual ZECOIN report.

Test your reasoning

P14-L01-Q1 · Which state best fits a missing provider measurement time?
P14-L01-Q2 · What must accompany an inferred claim?
P14-L01-Q3 · Does INSUFFICIENT EVIDENCE for same-controller attribution prove different controllers?
P14-L01-Q4 · What does OBSERVED mean for this fictional card?
P14-L01-Q5 · Can one report legitimately contain all four evidence states?