CheckD (the application)

https://checkd.io

CheckD is a simple app for issuing and using digital badges that prove something about a person or an organisation without exposing underlying data while also enabling verified data to also be shared if requested with full contractual permissions.

• Who it’s for
  • Everyday users who want to prove things about themselves safely (e.g. “I’m a resident”, “I hold this membership”, “I attended this training”).
  • Communities and organisations that want to issue and accept badges without building a complex identity or data system.
• What it does
  • Lets organisations issue badges based on rules (e.g. “only if the user’s PDA shows they are over 18 and lives in X city”).
  • Lets users hold badges in an app and present them when needed, like digital cards or passes.
  • Lets merchants/validators check badges to verify if a condition is met (e.g. “Is this person eligible?”) without seeing all the user’s data.
• What it doesn’t do
  • CheckD does not store users’ personal data in a central database.
  • It does not become the “source of truth” for identity or data. It is a proxy application that talks to the user’s own data infrastructure (HAT + Dataswyft Wallet).

In short: CheckD is the human-facing app that makes badges and proofs usable in everyday life.

Dataswyft Wallet (the infrastructure layer)

The Dataswyft Wallet is the invisible engine that powers CheckD and other apps.

• Role
  • It is a blind orchestrator:
    • It never takes custody of the data.
    • It enforces rules (from badge templates, data profiles, schemes) and coordinates flows between:
      • The user’s personal data accounts (PDAs) on HAT Microservers (https://www.hubofallthings.com/main/what-is-the-hat)
      • External issuers, validators, merchants, and services.
  • It ensures that trust and compliance come from the architecture, not from “just trusting” the app or a central database.
• What it manages
  • Badge templates and rules: who can issue, who can hold, under what conditions, and how a badge can be used.
  • Data profiles in the user’s Wallet namespace: structured data that satisfy badge rules (e.g. attributes like age-range, residency, membership status).
  • Orchestration flows:
    • Acquiring data (e.g. via connectors, DSARs, forms).
    • Transforming/aggregating data into profiles.
    • Minting badges when rules are met.
    • Presenting and validating proofs between issuers, holders, and verifiers.
• What it does NOT do
  • It does not become a data lake or data warehouse.
  • It does not see or store raw personal data centrally.
  • It does not break data custody: HAT Microservers remain the legal and technical point of custody.

In short: Dataswyft Wallet is the rule engine and traffic controller that makes self-custody, proofs, and badges work safely across many apps and organisations.

2. How they fit together

You can summarise the relationship like this:

• HAT Microserver + PDAs

  Where the user’s and organisation’s data actually lives and is owned (custody).

• Dataswyft Wallet

  The orchestrator that reads machine-readable rules, looks at what data is available in PDAs, and decides if a badge or proof can be issued / presented / accepted.

• CheckD

  The front-end app that people use to:

  • Receive and hold badges.
  • View what they can do with those badges.
  • Present them to communities and organisations that accept them.