01Executive Summary

One identity. One profile. Every layer.

Digital World gives every member one simple experience: create one Digital World identity, receive recovery words, receive a wallet, and immediately begin using Communication, Social, Payments, Marketplace, Storage, and Intelligence. No forced identity verification. No second sign-up. No second profile photo.

Verification is a later, optional step. A government program, bank, employer, school, or accredited verification provider issues credentials to the member-owned identity. Credentials add trust; they never create, replace, or control the identity.

This version (v3) aligns the specification to the published 12-layer LIFE stack, defines the repository strategy under gitlab.com/digitalworld, and specifies the machine-readable Layers Integration Module that feeds every public surface from this single source of truth.

Canonical endpoints

These four destinations are normative. Every layer page, doc, SDK, and repo link in this specification, on the public site, and in generated navigation resolves under one of them. Anything published elsewhere is a mirror, not a source.

02Core Principles

Every engineering decision in this document traces back to one of these.

04Identity Spine

How one root identity powers every layer without ever being exposed.

• Communication account equals endpoint.
• Social handle equals endpoint.
• Root identity equals ownership.
• Shared profile equals presentation.
• Derived keys equal service-specific authority.

05Onboarding: Words, Wallet, Go

Delayed verification is the default path, not an edge case.

1. Member installs Digital World.
2. Member selects Create Identity (or Restore with recovery words).
3. System generates the root identity and inception key event on device.
4. Member receives and confirms recovery words.
5. Wallet is created automatically; the member can send and receive payments immediately.
6. Communication, Social, and core services are provisioned with derived service identities.
7. Member sets the shared profile once: display name, photo, username, bio.
8. Verification is offered later, in context, when an action requires a credential.

06Shared Profile Service

The single source of truth for how a member appears, everywhere.

The Shared Profile Service prevents the classic failure where a member is "Bob" with one photo on one service and "Robert" with another photo somewhere else, and cannot remember which is which. Enter it once; every layer inherits it.

• Every service subscribes to the shared profile by default.
• Changes publish a profile.updated event; subscribed services converge within seconds.
• Services may support per-service overrides, but the UI must clearly show when an override is active.
• Members can remove an override at any time and return to the shared profile.
• Persona activation switches the presented profile atomically across participating services.

07Derived Service Identities

Independent keys per layer. One compromise never becomes twelve.

Each layer receives its own derived identity and key set from the root, using deterministic, member-recoverable derivation. This avoids one private key being reused everywhere and lets any single layer rotate or be replaced without touching the others.

08Communication and Social

Two layers, two derived identities, one member, one profile.

The existing Communication platform (Layer 09) is already live with its own identifier system, as shown in the current member identity screens. That identifier is hereby classified as a communication endpoint, not the root identity. The Social platform (Layer 10) receives its own derived identity but inherits the shared profile, so activating Social never asks the member to pick a second name or upload a second photo.

When a member who already has a Communication account activates Social, provisioning is silent: derive the Social identity, subscribe it to the shared profile, reserve the username if not yet reserved, done. The migration procedure for existing accounts is defined in Section 22.

09Verification and Credentials

Verification is credential issuance, never identity creation. Verifiable credential context

When trust is needed, the member verifies with an issuer and receives a chained verifiable credential bound to the root identity. The credential travels with the member, supports native partial attribute disclosure (prove "over 18" without revealing a birthdate), and can be revoked by the issuer without affecting the identity itself.

Issuer classes

• State and government identity programs (see SEDI, Section 16).
• Banks and financial institutions (verify by logging into an existing account).
• Accredited third-party verification providers, operated as OEM installations under Digital World branding.
• Employers, schools and universities, professional licensing organizations.

Credentials compose into endorsements: an issuer or a trusted member can endorse an attribute of another member's credential, building a trust network (Layer 05) without any central authority owning it.

10Personas

Different contexts, different resources, one root, zero confusion.

Personas let one member operate in different contexts without creating separate root identities. Each persona is a named view that bundles a presentation, a data scope, credentials, and communication resources. Switching personas switches all of them atomically.

• Persona resources (additional phone numbers, mailboxes, masked messaging channels) are provisioned through partner privacy APIs behind the Persona API; the partner is an implementation detail, never a member-facing brand.
• Each persona can pin its own credential set: the Professional persona presents Verified Employee, the Dating persona presents Verified Adult and nothing else.
• Persona separation is enforced at the data layer, not just the UI: vault scopes, graph partitions, and disclosure packages are persona-aware.
• Persona creation emits persona.created, which provisions resources across Communication, Social, and Storage.

11Digital Choice Act Data Layer

Request, receive, import, use, delete. The member drives every step.

Digital World includes a Data Portability and Request Engine that operationalizes data rights legislation (Utah Digital Choice Act model, GDPR, CCPA, and successors). It helps members request their data from external providers, track the legal clock, receive and validate archives, import them into the vault, and optionally delete the raw source files after successful import.

• Every request, receipt, import, and deletion is written to the member-visible audit log.
• Deadline tracking and provider response monitoring are handled by Intelligence (Section 15).
• Disclosure packages can be generated from imported data for specific use cases, with selective fields only.

12Import Framework

One adapter contract, many sources, persona-aware normalization.

Every import source implements the same adapter contract: detect → validate → extract → normalize → map → commit. Adapters live in gitlab.com/digitalworld/dw-import-adapters and are individually versioned against source archive formats.

• Raw archives are encrypted at rest in a quarantine area of the vault until normalization completes.
• Normalization produces typed records (contact, post, transaction, record, person, event) with provenance pointers back to the raw source.
• Duplicate detection and entity resolution across sources are performed by Intelligence with member confirmation.

13Member Data Vault

Layer 08: your data, encrypted, sharded, and yours to control.

The vault stores normalized member-owned data, credentials, graph data, documents, files, and persona-scoped resources. It is addressed by content, keyed to the member's derived storage identity, and sharded for backup across nodes the member chooses.

14Graphs and Lineage

Relationships are member data too.

Graphs live in the graph vault, are queryable through the Graph API, and are partitioned by persona scope. No graph is ever readable by the platform for advertising or profiling; Intelligence queries run under the member's own agent identity.

15Digital World Intelligence

Layer 11 serves the member. It is never a surveillance system for the platform.

• Summarize imported data and surface what matters.
• Detect duplicate contacts and records across sources; propose merges for member confirmation.
• Build and maintain relationship graphs, including the Lineage graph.
• Recommend persona organization ("these 214 contacts look professional; move to Professional?").
• Prepare formal data requests and track provider responses and legal deadlines.
• Generate disclosure packages with the minimum fields for a stated purpose.
• Operate only through scoped agent identities with member-granted, revocable, auditable authority.

16SEDI Reference Installation

State-Endorsed Digital Identity, demonstrated in production shape.

Digital World maintains a reference implementation for State-Endorsed Digital Identity concepts and a Digital Bill of Rights reference installation in Utah. It maps every legislative requirement to a shipping product flow, giving public sector, private sector, and member-owned trust a shared developer model.

The SEDI reference ships with example screens, reference APIs, and developer notes at docs.digitalworld.earth, with SDK and API references at docs.digitalworld.market.

17Repository and Branding Strategy

One namespace, one brand, upstream discipline.

Each layer is built on the strongest open source foundation available for its domain. Those upstream projects are forked into gitlab.com/digitalworld, rebranded under Digital World naming, and maintained with a documented upstream sync policy. Member-facing surfaces, marketing, and documentation reference only Digital World names.

Fork policy

• Brand at the edge, sync at the core. Rebranding is confined to naming, theming, and configuration layers so upstream security patches merge cleanly.
• Upstream names never surface. Package names, UI strings, docs, and public APIs use Digital World naming only. Upstream attribution and licenses are preserved in each repo per license requirements.
• Everything stays open. All forks and all Digital World original code remain fully open source. Nothing is described or licensed as proprietary.
• One CI convention. Every repo ships the same pipeline stages: build, test, license-check, brand-lint (fails on upstream name leakage into member-facing strings), and spec-sync against dwes.

18Layers Integration Module

One manifest feeds the spec, the site, and the docs portal.

The stack in Section 3, the public page at digitalworld.earth/layers, the docs at docs.digitalworld.earth, and the SDK and API portal at docs.digitalworld.market all render from a single machine-readable manifest, layers.json, published from gitlab.com/digitalworld/dwes. Changing a layer's name, chips, or links in the manifest updates every surface on the next deploy.

Manifest shape

{
  "standard": "LIFE",
  "version": "3.0",
  "endpoints": {
    "docs":   "https://docs.digitalworld.earth",
    "layers": "https://www.digitalworld.earth/layers",
    "sdks":   "https://docs.digitalworld.market",
    "code":   "https://gitlab.com/digitalworld"
  },
  "layers": [
    {
      "number": 6,
      "id": "finance",
      "name": "Finance Layer",
      "tagline": "Payments, assets, and value that you own.",
      "chips": ["Payments", "Wallet", "Assets", "DUSD", "Credit", "Exchange"],
      "repo": "https://gitlab.com/digitalworld/dw-finance",
      "docs": "https://docs.digitalworld.earth/finance",
      "sdk": "https://docs.digitalworld.market/finance/sdk",
      "api": "https://docs.digitalworld.market/finance/api",
      "anchor": "https://www.digitalworld.earth/layers#finance",
      "derivedIdentity": true,
      "availableUnverified": true
    }
  ]
}

Consumption contract

• digitalworld.earth/layers renders the 12 rows (number, name, tagline, chips) plus Code, Docs, SDK, and API buttons from the manifest, exactly as this document does in Section 3.
• docs.digitalworld.earth generates its top-level navigation and per-layer landing pages from the same manifest; each layer page hosts the guides and spec extracts for that layer at /<id>.
• docs.digitalworld.market hosts the SDK downloads, SDK guides, and API references per layer at /<id>/sdk and /<id>/api, generated from the same manifest.
• URL conventions are fixed: /layers#<id> on the site, docs.digitalworld.earth/<id> for docs, docs.digitalworld.market/<id>/sdk and /<id>/api for developer references, dw-<id> in the code namespace.
• Validation: CI in dwes validates the manifest against a published JSON Schema and checks every URL resolves before deploy.
• The manifest is served with CORS enabled so partner sites and the staging environment at staging.digitalworld.earth can embed the stack directly.

19API Surface

Every API is documented at docs.digitalworld.earth, with SDK and API references at docs.digitalworld.market, and versioned in its layer repo.

20Events and Synchronization

A small event vocabulary keeps twelve layers in agreement.

• Events are signed by the emitting derived identity and ordered per member.
• Consumers are idempotent; replaying an event stream reconstructs service state.
• Offline devices converge through the sync service in Layer 08.

21Security and Privacy

Defaults a member never has to configure.

• The root identity is never exposed as a public social handle or communication endpoint.
• Derived service keys are isolated; compromise of one layer never crosses into another.
• Public usernames reveal nothing about the root identity; identity display uses the first name plus derived key fragment convention, e.g. Avery DW8X...7K3D.
• Credentials support native partial attribute disclosure; full documents are never presented when a single attribute suffices.
• Personas prevent unintended cross-context leakage at the data layer, not just in the UI.
• Raw import files are encrypted in quarantine and deletable after normalization.
• All communication is end-to-end encrypted by default; vault content is encrypted with member-held keys.
• Every disclosure and every agent action is auditable by the member through the Audit API.
• Recovery words restore the root identity, the key event log restores derivations, and the sharded backup restores the vault.

22Communication Account Migration

Existing members upgrade in place; nothing breaks, nothing re-registers.

1. Identify the existing Communication account and its current identifier.
2. Create or restore the member root identity.
3. Map the existing identifier as the Communication endpoint under the root.
4. Provision the Communication derived identity and bind existing sessions to it.
5. Adopt the existing display name and image as the candidate shared profile.
6. If conflicts exist across devices or services, ask the member once which name and image become the shared profile.
7. Provision Social with its own derived identity, inheriting the confirmed shared profile.
8. Reserve preferred_username in the LIFE namespace if not already reserved.

23Roadmap

Seven phases, each shippable on its own.

24Engineering Acceptance Criteria

The build is done when every line below is demonstrably true.

• A member can create a Digital World identity without any verification, legal name, phone number, or email.
• A wallet is created automatically during onboarding and can send and receive payments immediately.
• The member receives recovery words and can restore identity, derivations, and vault from them.
• Communication and Social use separate derived keys and inherit the shared profile by default.
• A shared profile update syncs to all participating services within seconds.
• A member can create a persona with its own presentation, credential set, and communication resources.
• A member can request external data from a provider and track the response deadline.
• Imported data is normalized, persona-mapped, and committed to the vault with provenance.
• Raw imports can be deleted after successful import on the member's instruction.
• Credential issuance never replaces or controls the root identity, and revocation never damages it.
• A credential can prove a single attribute without disclosing the rest of the document.
• Social key rotation does not impact Communication, and vice versa.
• Replacing the Communication layer does not require root identity migration.
• The layers.json manifest validates in CI and renders identically in this spec, on digitalworld.earth/layers, and on docs.digitalworld.market.
• Brand-lint passes: no upstream project name appears in any member-facing string, package name, or public API.

Digital World Engineering Specification v3 · Fully open source · Founding services providers: ClearSoftware, ClearCenter, Digital World, ClearFoundation · staging.digitalworld.earth