Digital World is a neutral digital jurisdiction and utility platform for identity, payments, communications, agreements, governance, business, family, vehicles, property, and intelligent services.
This Knowledge Base and Standards document is the shared source of truth for Digital World, Clear Companies, Life Apps, partners, developers, jurisdictions, and future communities. It defines the principles, language, architecture, product layers, operating standards, and decision rules that guide the ecosystem. The deeper chain, asset, protocol, and infrastructure details live in the Engineering Specification, which pops out as its own reference alongside this document.
Digital World exists to help people, businesses, and communities own and control their digital lives. The mission is a trusted digital environment where:
The individual is the root of the system -not an account inside someone else's database.
Disclosure is limited, permissioned, portable, and revocable.
Identity, payments, agreements, and records in one framework.
Issue and recognize credentials without owning the person.
Councils, proposals, voting, and accountable decisions.
Simple, low-cost, private where legally possible.
Signed, stored, human-readable, and system-executable.
Without becoming a surveillance layer.
The individual is the root of the system. A person owns and controls their identity, credentials, wallet, records, relationships, agreements, permissions, reputation, and personal data.
Governments, banks, schools, employers, businesses, and churches may issue, verify, or endorse credentials. They do not own the individual's core identity.
Reduce unnecessary tracking, profiling, and centralized data collection. Privacy is the default; disclosure is limited to what is required.
Connect with existing systems through open standards, APIs, credentials, import/export tools, and modular services. Trusted digital life should be portable.
Identity, credentials, reputation, payments, communications, agreements, and governance survive vendor, brand, political, and platform changes.
Shared standards, interfaces, and reusable services -with separate data, separate permissions, and separate governance where needed.
Technology, automation, and Digital Intelligence assist humans; they never replace consent, accountability, rights, judgment, or governance.
| Role | Who | Function |
|---|---|---|
| Standards & jurisdiction layer | Digital World | Neutral standards, shared frameworks, and the digital jurisdiction itself. |
| Builders & operators | Clear Companies | Build, operate, and commercialize parts of the ecosystem. |
| Member-facing apps | Life Apps | Apps for people, communities, brands, businesses, cities, states, countries, and other jurisdictions. |
Ecosystem products
Use simple, human-readable names in public materials. Avoid leading with internal technical names in public-facing copy -the public should understand what each layer does without needing to understand the underlying technology.
Use “Digital Intelligence” instead of “Artificial Intelligence” when describing the Digital World ecosystem. Digital Intelligence is positioned as an assistant, not a replacement for human authority.
The 18-Layer Digital World Stack
Every public layer, linked all the way around the system: its Knowledge Base standard, its section of the Engineering Spec ↗, the SEDI reference installation ↗, and its API surface. Tap a layer to expand its standard.
The eleven core layers -Identity, Finance, Communication, Social, Agreements, Governance, Voting, Storage, Intelligence, Browser, and Builder -are the shared utility fabric of Digital World. Their full standards (what each layer supports and its governing principle) live in the interactive Layer Stack above, so every product, Life App, and jurisdiction references one canonical definition.
The person owns the identity. Institutions may issue credentials. Verifiers may check credentials. No institution becomes the permanent owner of the person's digital existence.
Domain layers with extended operating standards continue below: Business §8, Vehicle §9, Family §10, Ticketing §11, Property §12.
The Business Layer gives companies, merchants, nonprofits, associations, and organizations a trusted digital operating system: business identity, business wallet, credentials, merchant payments, employees, roles, permissions, locations, licenses, agreements, invoices, receipts, rewards, reviews, customer relationships, support, compliance, and Digital Intelligence assistance.
Business identity may include
A business should be able to operate digitally with identity, payments, agreements, communications, and records in one trusted framework.
The Vehicle Layer allows vehicles to become trusted digital objects: vehicle identity, ownership credential, registration credential, insurance credential, inspection credential, maintenance and warranty records, lien status, purchase agreements, bills of sale, fleet management, business ownership, authorized drivers, and digital plate verification via QR or tap.
Digital Plate Direction
Digital World prefers simple, durable, privacy-preserving vehicle verification. A plate or tag should allow authorized verification without enabling unnecessary mass profiling.
Vehicles should be verifiable without turning every driver into a tracked profile.
The Family Layer helps families manage relationships, records, history, photos, documents, permissions, and shared assets: family trees, family records, photos, stories, documents, children's records, education records, medical records where appropriate, property records, family agreements, trusts, inheritance planning, family wallet, family vault, permissions, and privacy controls.
Family data is highly personal and must be portable, private, permissioned, and protected.
The Ticketing Layer supports ownable, verifiable, transferable digital tickets: event identity, venue identity, ticket ownership, seat assignment, transfer rules, refund rules, entry verification, QR or tap access, expiration, payment receipt, organizer identity, reputation impact, and anti-fraud controls.
A ticket should be a trusted digital object owned by the buyer, not just a temporary barcode controlled by a platform.
The Property Layer supports digital records and agreements for land, homes, buildings, rentals, ownership, maintenance, access, and property transactions: property identity, owner credentials, tenant credentials, lease agreements, purchase agreements, maintenance records, access credentials, insurance, taxes and fees, HOA or community rules, utility connections, inspection records, property wallets, and property vaults.
Property records should become portable, trusted, and agreement-aware while protecting owner and resident privacy.
A Digital World jurisdiction may be a country, state, city, tribe, campus, community, business network, or digital-first community. Each jurisdiction defines:
State and Government Principle -the SEDI model
A government may issue or recognize credentials, but it should not own the person's decentralized identity. The preferred model -implemented end-to-end in the SEDI Reference Installation -is:
| Element | Standard |
|---|---|
| Individual-owned identity | The member holds the root identity; the state endorses it, never owns it. |
| Third-party service providers | Independent providers operate wallets, vaults, and services -citizen choice among multiple providers. |
| Government-issued / recognized credentials | Licenses, registrations, and status proofs issued as verifiable credentials. |
| Open standards | Interoperable credentials, APIs, and export so no vendor becomes a gatekeeper. |
Active and pilot jurisdictions
A Life App is the member-facing app for a place, community, brand, or purpose.
Every Life App includes
Optional modules
A Life App should be a trusted digital home for a member, not just another isolated app.
Every Digital World agreement includes:
Agreement types
Every agreement should be clear enough for a person to understand and structured enough for software to help manage.
Digital World payments support member payments, business payments, merchant checkout, QR payments, tap payments, wallet-to-wallet transfers, invoices, subscriptions, escrow, rewards, refunds, taxes and fees where required, agreement-linked payments, receipts, and external payment connections.
Wallet types
Payments should be simple, private where legally possible, low-cost, auditable where required, and connected to agreements when needed.
Members own personal data. Businesses own business data. Families control family data. Jurisdictions control jurisdictional records. Shared data requires permission.
Export, import, backup, restore, transfer, delete where legally possible, move between providers and Life Apps, open formats where practical.
Separated by member, family, business, jurisdiction, brand, application, tenant, role, permission, and legal requirement.
Credential issued/verified/revoked, agreement signed, payment made, vote cast, vehicle or ticket transferred, role updated, permission granted or revoked, agent acted -protecting privacy while preserving accountability.
Digital World must protect identity, wallets, credentials, agreements, payments, messages, documents, personal data, business data, family data, vehicle data, health data, voting data, children's data, and jurisdictional data.
Authentication
Recovery options
Recovery must be strong enough to help members regain access -but not so centralized that an institution can silently take over a member's identity.
Digital Intelligence agents must be permissioned. Each agent has:
Agents may assist with
An agent should never have more authority than the person, business, or council intentionally gives it.
20.1 Architecture
Digital World is modular: shared standards, shared reusable logic, shared APIs, a shared identity framework, a shared agreement framework, and a shared payment framework -with separate databases where needed, separate brand and jurisdiction configurations, separate permissions, and separate compliance rules.
20.2 API Standards
20.3 Repository Standards
20.4 Open Source Fork Standards
Respect upstream
Preserve licenses, credit the upstream source, rename clearly, and keep the upgrade path where practical. Avoid unnecessary rewrites.
Integrate Digital World
Document changes; add identity integration, payment integration where relevant, agreement integration where relevant, and Digital World branding.
Ship responsibly
Add deployment instructions and security review notes before release.
Digital World interfaces are clean, simple, light, modern, trustworthy, mobile-first, accessible, fast, credential-aware, wallet-aware, agreement-aware, and privacy-forward.
Preferred design direction
The member should always understand: who they are interacting with, what they are sharing, what they are signing, what they are paying, what they are approving, and what they can revoke.
Digital World uses layered moderation.
22.1Global Rules
No illegal content, child exploitation, fraud, impersonation, direct threats, non-consensual intimate content, malware, or platform abuse.
22.2Community Rules
Each community may add rules: family-safe, professional, adult restricted, local civic discussion, merchant-only, student-only, council-only, private group.
22.3User Controls
Block, mute, report, filter, restrict adult content, restrict unknown users, control visibility, comments, direct messages, and data sharing.
22.4Appeals
Moderation decisions support an appeal process where practical. Moderation is explainable, logged, and accountable.
Digital World Flow is the project and task management system for the ecosystem. It supports boards, lists, cards, status, owners, due dates, images, screenshots, descriptions, comments, files, labels, priority, dependencies, roadmap items, feature requests, bug reports, release planning, developer assignments, meeting notes, and DI summaries.
Future direction
Digital World treats important things as digital objects:
Every digital object has
The Digital World Knowledge Base is organized into ten sections. Deep technical documents -like the Engineering Specification -pop out as standalone references linked from here.
What is Digital World? · Mission · Principles · Ecosystem overview · Glossary · Current roadmap · Key links
Layer overview and the Identity, Finance, Communication, Social, Agreements, Governance, Voting, Storage, Intelligence, Browser, and Builder Layers → Layer Stack · Engineering Spec
Digital World · Utah Life · Idaho Life · ClearID · ClearPayments · ClearCommunity · ClearSoftware · ClearCellular · ClearNode · ClearHome · ClearCloud · ClearUnion · ClearBank · Flow · Agreements · Builder · Clear Autos · Digital Tickets · domain layers
Naming, identity, credential, payment, agreement, API, data, security, privacy, UI, repository, open source fork, and governance standards (§§5–22)
Utah Life · Idaho Life · New Zealand · Mexico · Tonga · Vanuatu · Canada · India · Future pilots → §13
Getting started, repositories, local setup, API docs, environment variables, authentication, identity / payment / communication / social / agreement integration, testing, deployment, security review → API Surface
Business model, merchant & partner onboarding, investor materials, subscription / licensing / revenue models, pilot / state / enterprise proposals, banking & payments, telecom, phones, vehicles, tickets
Templates: settlement, purchase, bills of sale, corporate guarantees, patent, subscription, merchant, user terms, privacy policy, content policy, data sharing, jurisdictional agreements → §15
Support, incident response, member / merchant / jurisdiction / issuer / verifier onboarding, release process, change management, roadmap, Digital World Flow → §23
Digital World · Life App · Member · Jurisdiction · Credential · Issuer · Verifier · Wallet · Agreement · Digital Intelligence · Council · Clerk · Agent · Vault · Node · Profile · Tenant · Layer
Every Digital World product must answer:
| Domain | Questions |
|---|---|
| Identity | Who is the member? What identity is being used? What credentials are required? |
| Permissions | What permissions are granted? Can the member revoke access? |
| Payments & agreements | What payments are involved? What agreements apply? |
| Data | What data is created? Who owns it? Where is it stored? Can the member export it? |
| Accountability | What is the audit trail? What Digital Intelligence agents are involved? What human approval is required? |
| Durability | What happens if the service shuts down? What happens if the member loses access? |
Approved short descriptions:
“Digital World is a member-owned digital identity, payments, communications, agreements, and governance platform.”
“Digital World helps people own their identity, control their data, make payments, sign agreements, and participate in trusted communities.”
“Digital World gives cities, states, countries, businesses, and communities a private, interoperable digital utility layer.”
“Digital World is a digital jurisdiction and utility framework that connects identity, payments, communications, agreements, data, governance, and Digital Intelligence.”
Roadmaps are organized by layer, product, jurisdiction, pilot, owner, priority, status, dependencies, target date, risks, and next action.
Preferred status labels
The following areas are treated as high priority:
When making product, technical, legal, or governance decisions, ask:
If the answer is yes, it likely fits the Digital World direction.
Digital World is built as a modular, standards-based, privacy-first digital jurisdiction. The correct long-term direction is not one giant backend, one giant database, one giant app, or one company-controlled platform. It is:
Digital World should become the trusted digital layer where people, businesses, governments, communities, and Digital Intelligence agents can interact safely, privately, and with clear agreements.
Digital World is not a first attempt. The teams behind the Clear companies helped create the managed service provider (MSP) industry -the model where independent local providers deploy, operate, and support technology for businesses and communities everywhere -and then built and shipped a full operating system on top of that model.
That operating system, ClearOS, was deployed at genuine global scale:
Why this history matters
That era proved three things the Digital World standards are built on: an operating system can be packaged so that independent providers -not one central company -deploy and operate it anywhere; software can ship through the world's largest hardware channels and still be owned and administered locally; and reference installations plus clear standards scale further than any single vendor ever could.
It also taught the limits of centralized technology. Even a globally successful centralized model leaves identity, data, and payments inside someone else's platform. Digital World takes the same distribution playbook -standards, reference installs, independent providers -and applies it to decentralized identity, payments, agreements, and governance, where the member, not the platform, is the owner.
The distribution model is proven; the ownership model is what changes. From centralized systems operated for people to decentralized systems owned by people.
This registry records the approved technologies of the ecosystem, in four statuses: Founding the standard we started on, Current the standard for new work, Emerging approved for pilots, and Maintain supported but not chosen for new builds. The codebase is the source of truth; this registry is updated in Digital World Flow as repositories are confirmed.
34.1 Frontend Standards
| Technology | Status | Standard |
|---|---|---|
| Angular | Founding | The framework Digital World originally started on. Existing Angular applications -admin consoles, dashboards, and early Life App builds -remain fully supported and continue to receive maintenance, security updates, and identity/payment/agreement integration. |
| TypeScript | Current | The default language across all frontend work, Angular and non-Angular alike. Strict typing on all new code. |
| React / Next.js | Current | The current standard reflected across the newer codebase for Life Apps, member-facing web experiences, and new dashboards. Server-rendered where SEO or first-load speed matters. |
| Upstream-native stacks | Current | Open source forks (per §20.4) stay in their upstream framework -Vue, Svelte, or otherwise -rather than being rewritten. Digital World identity, payment, and agreement integration is added in the upstream's own idiom. |
| Native mobile | Current | Life App mobile clients follow platform conventions (Swift / Kotlin) or an approved cross-platform framework where a repository has standardized on one -with wallet, keys, QR, and tap handled natively for security. |
Migration rule: no rewrites without cause (§20.4). Angular applications move to current standards only when a product reason exists, using strangler-pattern migration -new modules in the current standard alongside the working Angular app -never big-bang rewrites.
34.2 Identity & Credential Protocols
| Protocol | Status | Standard |
|---|---|---|
| W3C Decentralized Identifiers (DID) | Current | Root identifiers for members, businesses, devices, vehicles, agents, and jurisdictions. The individual holds the keys. |
| W3C Verifiable Credentials (VC) | Current | The format for everything institutions issue: licenses, registrations, memberships, roles, insurance, inspections. |
| OpenID4VC / OIDC | Current | Credential issuance and presentation flows, and bridge compatibility with existing login systems during migration. |
| WebAuthn / Passkeys | Current | Default authentication (§18) -phishing-resistant, device-bound, no shared secrets. |
| Selective disclosure (SD-JWT class) | Emerging | Prove age, status, or eligibility without exposing the full credential -the technical basis of Principle 3.3. |
| QR + NFC presentation | Current | The universal in-person layer: login, payment approval, agreement signing, plate and ticket verification. |
34.3 Backend & API Standards
| Technology | Status | Standard |
|---|---|---|
| Node.js + TypeScript | Current | Default runtime for shared services and Life App backends; one language across the stack. |
| REST + JSON, OpenAPI | Current | Every API documented, versioned, authenticated, permissioned, rate-limited, logged, and tested (§20.2). OpenAPI definitions are the contract. |
| Event vocabulary + webhooks | Current | The small shared event vocabulary from the Engineering Spec keeps layers synchronized without tight coupling; consumers are idempotent. |
| Upstream-native backends | Current | Forked services keep their upstream languages (PHP, Go, Python, etc.) per §20.4, wrapped with the standard identity, event, and API integrations. |
34.4 Data & Storage Standards
| Technology | Status | Standard |
|---|---|---|
| PostgreSQL | Current | Default relational store. Separate databases or schemas by tenant, brand, and jurisdiction per §17.3 -shared standards, separate data. |
| Encrypted member vaults | Current | Documents, credentials, and records encrypted at rest, permissioned by the member, exportable in open formats (JSON, CSV, PDF). |
| Object storage | Current | Media, backups, and archives -provider-portable so a member or jurisdiction can move hosts. |
| Caching / queues (Redis class) | Current | Ephemeral only. Nothing authoritative lives in a cache. |
34.5 Infrastructure Standards
| Technology | Status | Standard |
|---|---|---|
| Linux (ClearOS lineage) | Founding | The operating heritage of the ecosystem (§33) and the base of the ClearOS reference installations (§35). |
| Containers (Docker/OCI) | Current | Every service ships as a container image so any provider can run it on their own hardware. |
| Orchestration (Kubernetes class) | Current | For multi-service environments; single-node compose deployments remain a first-class option for small providers. |
| Infrastructure as code | Current | Terraform/Ansible-class definitions -every environment reproducible from the repository, which is what makes §36 automation possible. |
| CI/CD + observability | Current | Automated tests and releases per §20.3; logging, metrics, and audit trails per §17.4 with privacy preserved. |
Standards over uniformity: one identity framework, one agreement framework, one payment framework, one event vocabulary -while each repository uses the best-fit, maintainable technology for its job. Angular is where we started; the codebase is where the standard lives.
Just as SEDI is the reference installation for state-endorsed digital identity, the ClearOS family provides the reference installations for running Digital World services on your own infrastructure. The Clear companies stand these environments up as working examples -and third-party partners can deploy the same installations independently, on their own hardware, for their own members.
The proven server operating system -the platform behind 450,000+ deployments and pre-installed by Hewlett Packard Enterprise (§33). The reference installation for ClearNode: identity services, member vaults, payments connectivity, communication services, and Life App hosting operated by any provider, anywhere.
The member-device reference: Life App, wallet, credentials, passkeys, QR and tap -with the member's keys held at the edge, on the member's device, not in a central database.
The new desktop reference, with the Browser Layer built in as the trusted gateway (§7): credential presentation, wallet approval, agreement signing, and Life App access from a privacy-first desktop environment.
What a reference installation guarantees
Reference installations are examples, not gates. If a Clear company disappeared tomorrow, any provider running the reference installs could keep serving their members. That is the durability test (§26, §31).
We are standing these environments up today by hand and by script. The direction is that standing up a jurisdiction, a Life App, or a service provider node becomes an automated, declarative act -a manifest in, a running environment out -with Digital Intelligence doing the labor and humans holding the approvals.
How automation will actually occur
A manifest, not a project plan
An operator declares what they're standing up -jurisdiction or brand, domain, layers enabled, credential issuers, payment rules, agreement templates, governance model -in a Life App / jurisdiction manifest (the Layers Integration Module shape in the Engineering Spec).
The Builder Layer stands it up
Infrastructure as code (§34.5) provisions the environment from the reference installations (§35): domain, identity services, wallets, vaults, communication rooms, social space, agreement service, dashboards, monitoring, and backups -reproducibly, on the provider's own hardware or cloud.
Standards checking against this Knowledge Base
Automated checks run the Minimum Product Standard (§26) and Engineering Acceptance Criteria before anything goes live: identity works, credentials verify, payments settle, agreements sign, data exports, audit trails record.
DI agents run the routine, humans hold authority
Permissioned DI agents (§19) handle updates, monitoring, scaling, summaries, and standards drift -each with a named owner, scope, audit log, and human approval requirements. An agent never has more authority than it was intentionally given.
Every standup makes the next one easier
Fixes and improvements flow back into the reference installations and templates, so the ten-thousandth provider deploys in minutes what took the first providers months.
The trajectory
| Phase | Standing up an environment looks like |
|---|---|
| Today | Scripted deployments from the reference installs, with hands-on configuration by Clear teams and early partners. |
| Near term | One-command environments: manifest + Builder Layer = a running Life App or node, verified against §26 automatically. |
| Future | Conversational standup: describe the community or business to a Builder DI, review the generated manifest and agreements, approve -and the environment exists, on infrastructure the provider owns. Days become minutes; expertise becomes a template. |
Automation lowers the cost of standing up trusted digital infrastructure toward zero -while every consequential action still traces to a human approval, an audit trail, and a revocable permission.
The MSP industry proved that a standards-based model creates businesses everywhere at once: thousands of independent providers, each serving their own community, on shared technology. Digital World applies that same model to decentralized identity and decentralized payments -which tie into nearly every facet of life: commerce, family, vehicles, property, tickets, health, education, and governance.
The Clear companies are founding service providers, not gatekeepers. Everything they stand up -SEDI, the ClearOS reference installations, the Life App pilots -exists as a working example that others can study, deploy, and operate independently. Based on these examples, anyone can become a service provider to Digital World on their own.
Ways to build a business on Digital World
| Provider role | What you operate | Built on |
|---|---|---|
| Node operator | ClearNode-class infrastructure hosting identity, vault, and Life App services for a region or community. | ClearOS Server (§35) · Identity Layer |
| Identity / credential provider | Wallet services, issuance and verification services for institutions, schools, and employers. | Identity Layer · §34.2 protocols |
| Payment provider | Merchant checkout, wallet-to-wallet transfers, escrow, and agreement-linked payments for local businesses. | Finance Layer · §16 |
| Life App operator | The trusted app for a city, campus, tribe, brand, or community -its digital home. | §13 Jurisdictions · §14 Life Apps |
| Vault & records host | Member, family, and business vaults; document, property, and vehicle records with full portability. | Storage Layer · §17 |
| Integrator / developer shop | Connecting existing business systems, forking open source per §20.4, building modules and agreements. | §20 · §34 · API Surface |
| Vertical specialist | Vehicles and digital plates, ticketing, property, family history, health, or education services on the domain layers. | §§8–12 domain layers |
| Support & operations provider | The MSP model reborn: onboarding, monitoring, and support for members, merchants, and jurisdictions -assisted by DI (§36). | §25.9 Operations · §19 DI |
Why this is a massive opportunity for humanity
Every previous platform wave concentrated ownership: the platform owned the identity, the data, the payment rails, and therefore the businesses built on top. Digital World inverts that. Because the member owns the identity and the standards are open, the value of a provider's business belongs to the provider, and the member can never be held hostage -which is exactly what makes members, businesses, and jurisdictions willing to adopt it. Local providers serving local communities, on shared global standards, with no platform landlord.
Digital World succeeds when independent providers succeed. The Clear companies provide the examples; the world provides the providers. Shared standards. Separate businesses. Member ownership at the center.