OverviewD2

The questions nobody can currently answer

Mining project material sits with operators, laboratories, experts, government records, SPVs and issuers. The same item arrives at different dates in different units, and one changed source invalidates judgments made downstream of it.

Status: Problem statement
Whitepaper basis: §2.1 Fragmented Mining Information · §2.2 Information Asymmetry and Static Records · §2.3 The Core Problem
Verified on-chain today: None — nothing here is deployed yet
Still at design stage: Everything described as a remedy below

The failure is not that the documents are missing. It is that the relationships between them are not recorded anywhere, so each new reader reconstructs them by hand — and reaches a slightly different answer.

Eight questions the current workflow cannot answer

Which document, and which version of it, is this figure from?
Who reviewed it, and what were that person's credential and review scope?
Which items are confirmed, and which are simply not yet confirmed?
Has the underlying source changed since the last judgment was made?
Who decided to support the project, and who decided the legal issuance?
How do I know the published record was not quietly edited afterwards?
Is the record absent from the official source, unavailable because of an outage, or genuinely not applicable?
Was the credential that was valid at review time later expired or revoked?

Each of those has a different remedy, and collapsing them into a single green tick is how due diligence quietly fails.

Common failure	What the Registry records instead
A figure is quoted with no traceable origin	Claim → evidence version → source receipt → authority scope, as separate linked records
A review is treated as blanket approval	Attestation with a mandatory scope and limitation, signed against a frozen snapshot
An API returning `200` is read as verification	Twelve distinct source results, of which only one is `confirmed_from_source`
An updated source silently invalidates old conclusions	Change monitoring marks dependent records `stale_candidate`, then `suspended` if a blocking requirement weakens
A correction overwrites the previous public record	A new version supersedes the old one; the old version and its credential state at the time stay visible

Common failure
A figure is quoted with no traceable origin
What the Registry records instead
Claim → evidence version → source receipt → authority scope, as separate linked records
Common failure
A review is treated as blanket approval
What the Registry records instead
Attestation with a mandatory scope and limitation, signed against a frozen snapshot
Common failure
An API returning 200 is read as verification
What the Registry records instead
Twelve distinct source results, of which only one is confirmed_from_source
Common failure
An updated source silently invalidates old conclusions
What the Registry records instead
Change monitoring marks dependent records stale_candidate, then suspended if a blocking requirement weakens
Common failure
A correction overwrites the previous public record
What the Registry records instead
A new version supersedes the old one; the old version and its credential state at the time stay visible

What this does not do

It is not a document management system: files are the input, the linked claim is the product.
It does not attempt to score or rank projects.
It does not present an unresolved conflict between two sources as a settled figure.

This chapter is a public adaptation of the internal product specification. Where the two differ, the specification and the whitepaper govern.

MPC dApp Guide · design & build stage · synthetic demo data