Trust Model Graph¶
Date: 2026-04-12
Purpose: - show how the trust-model documents relate to each other - make it easier to move from research to architecture to scanner behavior
Diagram color key
Color encodes function, not trustworthiness: blue marks foundations and inputs, violet marks architecture and scanner components, amber marks policy or decision points, red marks blocking outcomes, and green marks a positive verified outcome. Select any diagram to open the interactive zoom-and-pan view.
Document Dependency Graph¶
graph TD
A[Published QR trust paper
conceptual foundation] --> B[PROJECT_OVERVIEW.md
PoC orientation] B --> T[TRUST_MODEL.md
platform trust architecture] T --> C[TRUST_LAYERS.md
issuer trust vs destination binding vs runtime safety] T --> D[TRUST_TIERS.md
unverified to verified institution] T --> E[ENROLLMENT_AND_CONSENT_MODEL.md
issuer onboarding and monitoring consent] T --> F[SCANNER_UX_STATES.md
user-facing scanner states] T --> G[SCANNER_DECISION_MATRIX.md
policy table] C --> F C --> G D --> F D --> G E --> T E --> D F --> G classDef foundation fill:#eaf2ff,stroke:#1d4ed8,color:#172033,stroke-width:2px; classDef architecture fill:#f1edff,stroke:#7c3aed,color:#2e2153,stroke-width:1.5px; classDef governance fill:#fff6db,stroke:#d97706,color:#4a2b05,stroke-width:1.5px; classDef experience fill:#e8f8f5,stroke:#0f766e,color:#123c38,stroke-width:1.5px; classDef decision fill:#e8eefc,stroke:#334e9a,color:#172554,stroke-width:2px; class A foundation; class B,T architecture; class C,D,E governance; class F experience; class G decision;
conceptual foundation] --> B[PROJECT_OVERVIEW.md
PoC orientation] B --> T[TRUST_MODEL.md
platform trust architecture] T --> C[TRUST_LAYERS.md
issuer trust vs destination binding vs runtime safety] T --> D[TRUST_TIERS.md
unverified to verified institution] T --> E[ENROLLMENT_AND_CONSENT_MODEL.md
issuer onboarding and monitoring consent] T --> F[SCANNER_UX_STATES.md
user-facing scanner states] T --> G[SCANNER_DECISION_MATRIX.md
policy table] C --> F C --> G D --> F D --> G E --> T E --> D F --> G classDef foundation fill:#eaf2ff,stroke:#1d4ed8,color:#172033,stroke-width:2px; classDef architecture fill:#f1edff,stroke:#7c3aed,color:#2e2153,stroke-width:1.5px; classDef governance fill:#fff6db,stroke:#d97706,color:#4a2b05,stroke-width:1.5px; classDef experience fill:#e8f8f5,stroke:#0f766e,color:#123c38,stroke-width:1.5px; classDef decision fill:#e8eefc,stroke:#334e9a,color:#172554,stroke-width:2px; class A foundation; class B,T architecture; class C,D,E governance; class F experience; class G decision;
System Relationship Graph¶
graph LR
Issuer[Issuer] --> Enroll[Enrollment Authority]
Enroll --> Tier[Trust Tier]
Enroll --> Dest[Approved Destination Set]
Enroll --> Consent[Monitoring Consent]
Generator[QR Generator] --> QR[Signed QR]
Enroll --> QR
Dest --> QR
QR --> Scanner[Scanner Platform]
Tier --> Scanner
Dest --> Scanner
Scanner --> Runtime[Runtime Safety Provider]
Consent --> Runtime
Runtime --> Risk[Runtime Safety Result]
Tier --> Decision[Scanner Decision Engine]
Dest --> Decision
Risk --> Decision
QR --> Decision
Decision --> UX[Scanner UX State]
classDef actor fill:#f8fafc,stroke:#64748b,color:#1e293b,stroke-width:1.5px;
classDef governance fill:#eaf2ff,stroke:#2563eb,color:#172554,stroke-width:1.5px;
classDef artifact fill:#f1edff,stroke:#7c3aed,color:#2e2153,stroke-width:2px;
classDef scanner fill:#e8f8f5,stroke:#0f766e,color:#123c38,stroke-width:2px;
classDef runtime fill:#fff6db,stroke:#d97706,color:#4a2b05,stroke-width:1.5px;
classDef decision fill:#e8eefc,stroke:#334e9a,color:#172554,stroke-width:2px;
classDef outcome fill:#e9f8ee,stroke:#15803d,color:#153d24,stroke-width:2px;
class Issuer,Generator actor;
class Enroll,Tier,Dest,Consent governance;
class QR artifact;
class Scanner scanner;
class Runtime,Risk runtime;
class Decision decision;
class UX outcome;
Scanner Decision Flow¶
flowchart TD
A[Scan QR] --> B{QR decodes?}
B -- no --> X[Show decode failure]
B -- yes --> C{Signature and schema valid?}
C -- no --> Y[Blocked]
C -- yes --> D{Issuer enrolled?}
D -- no --> U[Unverified or signed unaccepted issuer]
D -- yes --> E{Destination still issuer-approved?}
E -- no --> V[Destination changed]
E -- yes --> F{Runtime safety clear?}
F -- no --> W[Verified issuer, destination risky]
F -- yes --> Z[Verified issuer]
classDef input fill:#eaf2ff,stroke:#1d4ed8,color:#172554,stroke-width:2px;
classDef gate fill:#fff6db,stroke:#d97706,color:#4a2b05,stroke-width:1.5px;
classDef caution fill:#fff0d8,stroke:#c2410c,color:#4b230c,stroke-width:2px;
classDef blocked fill:#fff0f1,stroke:#dc2626,color:#4c1518,stroke-width:2px;
classDef verified fill:#e9f8ee,stroke:#15803d,color:#153d24,stroke-width:2px;
class A input;
class B,C,D,E,F gate;
class U caution;
class X,Y,V,W blocked;
class Z verified;
How To Read This Set¶
-
Start with the published paper and project overview. These separate the conceptual argument from what the current PoC implements and evaluates.
-
Move to TRUST_MODEL.md. This is the top-level architecture.
-
Use the specialized documents to pressure-test the model:
- TRUST_LAYERS.md
- TRUST_TIERS.md
- ENROLLMENT_AND_CONSENT_MODEL.md
- SCANNER_UX_STATES.md
- SCANNER_DECISION_MATRIX.md
Current Gap¶
The main unresolved design question across all these documents is:
- who operates the enrollment authority and trust-root program for ordinary consumer QR destinations?
That is the strongest unresolved dependency in the whole model.