# Evidence, verification, results and acceptance

Evidence is broken into atomic claims, supporting or contradicting fragments, sources and processing lineage; each verification method is recorded separately and verification status is not a single score; technical checks and commercial acceptance are kept apart.

> Document ID: MYRILUM-DOC-ARCH-021
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: 101ebe3f302c57f6ab201b364c3b1a2d1bb2166d656e0de755bd700b3d0a5562
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/evidence-and-acceptance

<a id="overview"></a>

## What this map shows

![Evidence, verification, results and acceptance diagram (A21)](/figures/atlas-v2-2/A21.png)

*MYRILUM architecture map v2.2 · A21 (public edition). Labels are in Chinese; every element is listed in English below. Select the diagram to open it at full size.*

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

Build a basis that can be re-checked, without creating the illusion that several models agreeing makes something true.

Verification supports a conclusion; acceptance decides whether a delivery meets what was agreed; the two are expressed in different records.

<a id="part-1"></a>

## Claims and the structure of evidence

| Field | Value |
|---|---|
| Atomic claim | A clear object, time, indicator, scope and claim type |
| Supporting or contradicting fragment | The fragment, its place in the original and how it relates to the claim |
| Source record | Original source, publication time, snapshot and licence |
| Citation and processing lineage | Secondary citation, data transformation, calculation and model processing |

> **Proof is not absolute truth** — Source, signature, processing or verification status can be proved; a hash, certificate or on-chain record alone never proves that real-world content is correct.

<a id="part-2"></a>

## Each verification method is recorded separately

| Field | Value |
|---|---|
| Fact and citation check | Whether the original supports it, and whether definitions and dates match |
| Calculation and data check | Code, inputs, units, the calculation and reproducibility |
| Independence and conflict | Reposts of the same source are de-duplicated; differing conclusions keep their disagreement |
| Model and method validation | Assumptions, samples, baselines, uncertainty and where it breaks down |

> **Evidence differs in strength** — A locatable source, a re-checkable calculation, independent observation and experimental validation are not the same kind of evidence.

<a id="part-3"></a>

## Verification status is not a single score

| Field | Value |
|---|---|
| Unverified or incomplete | Missing material or an unmet method never passes itself off as a pass |
| Supported or conditional | States the scope of support, the type of evidence and the limits |
| Conflicting or unsupported | Counter-examples and inconsistencies are kept and trigger a re-check |
| Correction or withdrawal | A new record is appended and linked to affected results and notices |

> **Verification is not acceptance** — A verification result is only an input to acceptance; whether a delivery is accepted is decided by an authorized user for a specific version of the result.

<a id="part-4"></a>

## Technical checks are kept apart from commercial acceptance

| Field | Value |
|---|---|
| Result version | Content, data, hash, sources and limitations |
| Check against delivery standards | Verification results can be an input but are never the final acceptance |
| Acceptance by an authorized user | Bound to a specific result version; a requested revision creates a new version |
| Archiving and traceability | Old versions are never overwritten; later corrections can be traced |

> **No scores out of thin air** — Without calibration data, no precise-looking confidence percentages or quality guarantees are produced.

<a id="source"></a>

## Source

This page follows A21 of the MYRILUM architecture map v2.2 (public edition: restricted products and internal open items are left out). Related: “Business domains and fact authority”; “The industry research agent: complete delivery”; “Commands, events and consistency”.

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.