Trust Architecture
Provenance, evidence, confidence, authority and audit across boundaries
When data crosses from one organisation to another, trust does not travel with it by itself. This line of research asks what has to travel instead.
Trust is not transitive
A supplier trusts its own records. A buyer trusts its supplier. An authority trusts neither by default. If each party simply inherits the trust of the previous one, the weakest record in the chain decides what everyone believes.
So each hand-over needs something that can be checked rather than believed: the value, where it came from, what supports it, who reviewed it and under which rules.
What each boundary checks
- Producervalue · provenance · evidence · review
- Exporter✓ checksvalue · provenance · evidence · review
- Importer✓ checksvalue · provenance · evidence · review
- Authority✓ checks
Every hop checks what it receives. Nothing is inherited just because the previous party accepted it.
Text description of the diagram
Four parties in a row: a producer, an exporter, an importer and an authority. Between each pair, what passes is not trust but a package of value, provenance, evidence and review record. Each receiving party checks that package itself. A dashed line from producer to authority is crossed out, showing that trust does not pass automatically through the chain.
Six elements
- 01
Provenance
Where a value came from: the source document, the system and the moment.
- 02
Evidence
What supports the value, kept beside it rather than in a separate report.
- 03
Confidence
A level per attribute, not per document, so that one weak field cannot hide inside a strong file.
- 04
Authority
Who may accept, override or publish, bound to a role rather than to whoever happens to be logged in.
- 05
Audit
An append-only, hash-chained trail with one trace identifier from intake to publication.
- 06
Boundaries
What a receiving party actually gets: the value, its evidence and the rules it passed, in open formats.
Where it is implemented
In AnyLAI this view is implemented as two platform components: the Trust Corridor, the runtime path from source documents to a composed digital product passport, and the Trust Console, the human surface for review.
Confidence attaches per attribute. Low confidence holds issuance until a registered person resolves it. The audit trail is hash-chained with an end-to-end trace identifier; the chain is not yet anchored outside the system.
Formats follow public standards: the UN/CEFACT UNTP data model for the passport, W3C Verifiable Credentials for the credential and GS1-compatible identifiers.
What this does not claim
What this does not claim
- Verifying is not certifying. The architecture records what was checked and by whom; it does not make a shipment legal or replace an operator's due diligence.
- Verification of the production credential by external standards verifiers has not been completed, so independent verifiability is not claimed here.
- Implemented code does not imply universal transitive trust, legal conformity or standards conformance.
Related research and projects
COADFPublished framework
The principles this architecture implements: confidence gating, human review by architecture, one trace end to end.
COADFAnyDPPResearch and demonstration environment
Where the architecture runs end to end, in a research and demonstration environment.
AnyDPPAnyTraceResearch prototype · unpublished
Provenance and custody as events on a timeline that can be reconstructed.
AnyTraceAnyVerifyResearch prototype · unpublished
Whether the available evidence supports a specific claim, attribute by attribute.
AnyVerifyAnyValidResearch prototype · unpublished
Whether an authoritative source confirms a claim, and whether that confirmation is still current.
AnyValid