Docs

Search and contents

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.

In developmentNot availableVerified

Evidence, verification, results and acceptance diagram (A21) (open full-size figure)
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.

What this map shows

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.

Claims and the structure of evidence

Atomic claimA clear object, time, indicator, scope and claim type
Supporting or contradicting fragmentThe fragment, its place in the original and how it relates to the claim
Source recordOriginal source, publication time, snapshot and licence
Citation and processing lineageSecondary citation, data transformation, calculation and model processing

Each verification method is recorded separately

Fact and citation checkWhether the original supports it, and whether definitions and dates match
Calculation and data checkCode, inputs, units, the calculation and reproducibility
Independence and conflictReposts of the same source are de-duplicated; differing conclusions keep their disagreement
Model and method validationAssumptions, samples, baselines, uncertainty and where it breaks down

Verification status is not a single score

Unverified or incompleteMissing material or an unmet method never passes itself off as a pass
Supported or conditionalStates the scope of support, the type of evidence and the limits
Conflicting or unsupportedCounter-examples and inconsistencies are kept and trigger a re-check
Correction or withdrawalA new record is appended and linked to affected results and notices

Technical checks are kept apart from commercial acceptance

Result versionContent, data, hash, sources and limitations
Check against delivery standardsVerification results can be an input but are never the final acceptance
Acceptance by an authorized userBound to a specific result version; a requested revision creates a new version
Archiving and traceabilityOld versions are never overwritten; later corrections can be traced

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”.

Was this page helpful?

MYRILUM platform architecture overviewSee how participants, the unified entry, business platform domains, the shared core, the agent layer, the execution network and infrastructure are layered, and how governance runs through all of them.Business domains and fact authorityEvery kind of official record has exactly one owner that may write it: how the twelve business domains divide the work, how product views map onto them, and why suggestions and official records stay separate.The industry research agent: complete deliveryThe first official product direction: the research method is its own, while identity, authorization, execution, files and metering reuse the platform. Its value is a traceable research process and reliable delivery.Commands, events and consistencyIn-domain transactions, cross-domain events, derived views and external side effects are handled separately; there is no promise of global exactly-once execution, but duplicates, delays and reordering never produce a wrong result.What is available now?What MYRILUM officially operates today: distinguish website browsing, the member store, scoped delivery and component records, and check availability for the region and account.
Sources and maintenance
Region
Global
Version
0.1.0
Publication
Published globally
Document status
Approved · Drafted
Authorization
Public information
Command authority
None
Type
Concept
Audience
Technical leads, Developers, Organization leaders, Integration partners, Agents
Safety class
Informational
Agent tasks
understand_platform_architecture
Owner
Web3Capital Documentation Steward
Last verified
2026-09-23
Review due
2026-10-23
Source commit
6b41cce4496d
Canonical authority
SRC-ARCHITECTURE-ATLAS-V2-2
Content digest
101ebe3f302c57f6
Stable citation
MYRILUM-DOC-ARCH-021@0.1.0:en#overview

Machine-readableMarkdownMetadataJSON-LDChunks

This documentation grants no execution, release, or production authority.

Sources and maintenance

Region
Global
Version
0.1.0
Publication
Published globally
Document status
Approved · Drafted
Authorization
Public information
Command authority
None
Type
Concept
Audience
Technical leads, Developers, Organization leaders, Integration partners, Agents
Safety class
Informational
Agent tasks
understand_platform_architecture
Owner
Web3Capital Documentation Steward
Last verified
2026-09-23
Review due
2026-10-23
Source commit
6b41cce4496d
Canonical authority
SRC-ARCHITECTURE-ATLAS-V2-2
Content digest
101ebe3f302c57f6
Stable citation
MYRILUM-DOC-ARCH-021@0.1.0:en#overview

This documentation grants no execution, release, or production authority.