Security · Data Integrity · Evidence Reliability
Verifiable, tamper-evident
mineral data
AssayChain treats the security and integrity of data and data processing, and the authentication of people and devices, as first-class research concerns. The core research contribution is evidence reliability — measuring, with published error rates, whether extracted mineral evidence can be trusted across five dimensions: fidelity (is it read correctly), completeness (was the relevant evidence captured), consistency (does independent evidence agree, and is an outlier an error or a real signal), provenance (can it be traced to source), and evidentiary sufficiency (is it enough to act on)? That layer sits on a content-addressed attestation pipeline that makes every number tamper-evident, without requiring trust in a central authority.
Because the parties to a mineral deal have opposing interests, data integrity cannot rest on trust in a single database.
The Technical Problem
No standard integrity layer for geological and assay data
Legacy geological and assay data lacks a standardized integrity layer. Provenance is fragmented across PDFs, lab certificates, and agency databases, and there is no cryptographic link between a raw source document and the structured data extracted from it.
A buyer who receives a number has no independent way to confirm it came from the document it claims to, and no way to detect silent modification after delivery. Critical-mineral supply-chain decisions, ESG disclosures, and reserve estimates are routinely made on data whose origin cannot be verified.
There is a second, deeper gap: even when a document's origin is known, no one measures whether the AI that transcribed it got the numbers right. Extraction errors are silent and unbounded — a model can mis-read a grade or coordinate and emit confident-looking JSON with no error rate attached.
This is the gap the protocol addresses: a verifiable, content-addressed link from source to delivered data, with no central authority required to trust it.
The Innovation
Trustworthy interpretation of mineral evidence
Provenance attests where data came from; it does not yet attest whether the data can be trusted. That is the research: a pipeline that turns extracted mineral data into measured, reliable evidence — so an agent or analyst knows not just what the numbers say, but whether the evidence is sufficient to act on them. Phase I models reliability along five dimensions:
Fidelity
Does extraction reproduce the source, with a published error bound? Already live as a benchmark harness.
Completeness
Was the relevant evidence captured — or are rows, columns, and pages missing?
Consistency
Does this evidence agree with independent extraction and other documents — and is an outlier an error or a real signal?
Provenance
Can every assertion be traced back to its source document, page, and table?
Evidentiary sufficiency
Is there enough reliable evidence for the specific question asked — or should the agent refuse to answer?
Phase I asks the falsifiable question: can an evidence-aware agent measure that sufficiency and, when it falls short, refuse — making measurably fewer unsupported claims than a baseline LLM/RAG agent? We do not pretend to know the answer; the point of Phase I is to find out experimentally.
The provenance layer
A content-addressed attestation pipeline
Three properties distinguish the protocol from database-backed provenance:
Content addressing
A file identifier is derived from its content. Any change to the data changes the identifier, making tampering self-evident — no trusted server required to detect it.
Signed attestations
Each result is bound to a typed, signed record committed to a public attestation registry. The signing key is the operator identity; records are permanent under a locked schema.
Machine-accessible delivery
The pipeline is exposed through a machine-to-machine API (REST + Model Context Protocol), so autonomous systems can retrieve and independently verify data programmatically.
How the protocol works
From source to verifiable response
1. Capture. Source data is recorded against locked schemas.
2. Content-address. The normalized record is stored in content-addressed storage; its CID identifies it uniquely.
3. Attest. A signed attestation commits the record fields and CID to a public schema registry.
4. Deliver. API responses carry the attestation UID and content-addressed CID, so any consumer can verify the chain without contacting AssayChain.
Security of Data and Data Processing
Tamper-evidence without a trusted server
Data is stored content-addressed: its identifier is a cryptographic function of its contents, so any modification produces a different identifier. Tampering is therefore detectable by any party, without access to a trusted copy of the data.
Each result is additionally bound to a permanent, typed attestation committed under a locked schema. Because records are append-only and schema-locked, a record cannot be silently rewritten after delivery — a change requires a new record, which remains visible against the original.
Authentication of People and Devices
Binding identity to data
People / operators. Each attestation is signed by a key that identifies the operator. Key rotation, revocation, and key-transparency logging are on the Phase I roadmap, so identity is governed rather than treated as a permanent single point of failure. A verifier can confirm who produced a record without trusting a directory or a central authority.
Devices. Field data is captured under a device-agnostic envelope — run identity, date, site district, feed type, and device description are committed — so heterogeneous capture devices produce uniform, attributable records.
Consumers. API access is authenticated per request: paid calls carry a signed payment authorization, and API-key or credit-based access is available for account holders. No shared long-lived secret is exposed beyond what the caller holds.
Properties
Threats and the mechanism that addresses them
| Property | Mechanism |
|---|---|
| Tamper-evidence | Content addressing — any change alters the identifier |
| Non-repudiation of origin | Signed attestations under a locked, typed schema |
| Auditability | Append-only records in an independent public registry |
| Operator identity | Attesting key as the source of truth |
| Device heterogeneity | Device-agnostic committed envelope |
| Consumer authentication | Per-request signed payment authorization / API keys |
Broader Impacts
Verifiable data for national mineral security
Critical-mineral supply chains, defense procurement, and clean-energy transitions depend on geological and assay data that is currently unverifiable. A standard provenance layer makes that data auditable end-to-end.
Because the protocol is open and content-addressed, it lowers the barrier to independent verification for small operators, analysts, and agencies alike — no proprietary gatekeeper stands between a source document and the data derived from it.
Model and data-flow disclosure
How data is processed
Extraction runs on Gemini 2.5 Flash (Google); the enrichment/sanitization pass on DeepSeek or GLM; question-answering synthesis on Groq. We disclose every model in the pipeline and are migrating compliance-sensitive enrichment to US-hosted or self-hosted inference.
Client documents are never used to train any model, ours or a provider's. Each call sends only the data needed to complete that call. Sensitive fields — site coordinates (rounded to ±0.1°) and personal identifiers — are redacted before storage and delivery. Account and API-key data is retained while an account is active; paid responses are cached for 30 days and then expire, while attestations and content-addressed source references are permanent by design.
Research scope
What is core, and what is assistive
Fidelity-verified extraction, on a provenance protocol, is the core research contribution. Extraction, benchmarks, and derived intelligence endpoints (risk, compliance, ESG) are assistive tools built on top of it; they are labeled research context and require Qualified Person review before regulatory use.
We state this plainly because the value of a provenance protocol depends on it never overstating what it certifies: an attestation confirms source, authenticity, and normalization — it does not certify that geological or assay values are true.