Crowd-Reference Sheet

Canonical Definitions, Domains, and Derivative Expressions

Purpose of This Document

↑ Back to Contents

This document provides a single, authoritative reference for all terminology, mechanics, and domains associated with the Crowd-Device and its derivatives. It exists to prevent semantic drift, misinterpretation, and fragmentation of the invention across documents, cases, and public discourse. The Crowd-Device did not give rise to a single product or platform. It established a generalised participation engine capable of operating across multiple domains. As that engine has been adopted, repurposed, and in some cases inverted, a wide range of “crowd-based” systems have emerged. This document clarifies how those systems relate to the original invention.

This reference sheet is explanatory, not argumentative. It does not advance claims by rhetoric, but by definition and structure.

The Crowd-Device

↑ Back to Contents

The Crowd-Device is the original, authored system that codifies a participation mechanism into a reusable architectural form. It enables populations — whether local or remote — to participate in decisions and outcomes through a shared mechanism. It is not a platform, a website, or a technology stack. It is an abstract participation architecture that may be expressed through paper processes, broadcast media, digital networks, or software systems.

Prior to this invention, participation mechanisms — including digital ones — were constrained by at least one of three limitations: they were either bespoke, captive, or embedded. The Crowd-Device resolved all three limitations by stripping back and codifying the primary participation mechanic into a unified templated architecture that can be reused across all domains, mediums, or wrappers, and deployed beyond captive local audience contexts too. Any of these capabilities, independently or together, constitutes use of the invention.

Accordingly, a system operating locally remains outside scope only where participation mechanics are embedded, instance-bound, bespoke, and/or captive, and not abstracted for cross-domain, cross-wrapper, or remote reuse. Use of the invention arises where the participation mechanic is abstracted into a transferable template, enabling any event, poll, competition, petition, or other instance to be overlaid without redesign, permitting cross-domain, medium, or wrapper reuse, and/or remote participation.

At its core, the Crowd-Device allows many inputs toward a common objective, tests those inputs against declared conditions, and triggers outcomes whether thresholds are met or not. The power lies in its neutrality, liberation, and transferability of the mechanic, where the same structure can be used to empower communities, fund innovation, coordinate action, or — when inverted — to control populations.

The Crowd-Mechanic

↑ Back to Contents

The Crowd-Mechanic is the operating logic of the Crowd-Device. It is defined by a simple but powerful pipeline:

• a token (an individual contribution or input),
• measured against a threshold (a declared condition),
• producing an outcome dependent on if or when the threshold is met.

This mechanic is domain-agnostic. It does not care whether the token represents money, a vote, labour, consent, or compliance. The meaning of the system depends entirely on who controls the tokens, who defines the thresholds, and who executes the outcome.

The Crowd-Mechanic is the engine from which all Crowd-* expressions derive.

The Crowd-OS

↑ Back to Contents

The Crowd-OS refers to the structural framework that allows the Crowd-Mechanic to operate reliably at scale. It is not software in the narrow sense, but an operating system in the architectural sense.

The Crowd-OS includes concepts such as declared thresholds, escrow or conditional holding, auditability, rotation or distribution of authority, and visible outcomes. These features distinguish the Crowd-Device from ad-hoc participation or one-off voting exercises. They are what transform ordinary human acts into a repeatable, transferable system. Where these structural features are absent, the system remains an ad-hoc instance rather than an implementation of the Crowd-Device.

Primary Domains of Application

↑ Back to Contents

The Crowd-Device was first articulated across four primary domains. These domains are original but not exclusive. They represent early, clearly identifiable applications of the same underlying engine.

Crowd-Funding

Crowd-Funding applies the Mechanic to capital and resources. People contribute financial tokens toward a declared objective, tested against one or more thresholds. Depending on the declared model, outcomes may include full commitment, partial execution, staged release, or reversion/refund where conditions are unmet. This allows for both all-or-nothing and keep-what-you-raise structures, while preserving the underlying token → threshold → outcome architecture. The engine stays fixed. Only the declared conditions differ.

Crowd-Voting

Crowd-Voting applies the Mechanic to collective choice. Tokens show a preference within a participation system. Aggregation rules or thresholds determine how and when outcomes are produced, and host systems rely upon outcomes for execution, visibility, or further action, including elimination, advancement, ranking or win/lose determinations. This is distinct from purely symbolic or advisory opinion polling that collects inert data, where responses produce no systemic action and are not relied upon by the host system. Where polling mechanisms trigger thresholds, aggregation, ranking systems, visibility, moderation, or other downstream effects, they function as derivative expressions of Crowd-Voting regardless of label.

Crowd-Action

Crowd-Action applies the Mechanic to labour, effort, capability, or coordinated contribution. Tokens may represent time commitments, productive capacity, skills, tooling availability, or willingness to act. Thresholds determine whether collective action proceeds, ensuring that effort is only expended when sufficient participation exists. This domain includes scenarios where multiple actors share execution rather than centralising risk in a single party. For example, manufacturers may commit partial tooling, production capacity, or resources toward a shared output, allowing cost, risk, and effort to be distributed across the crowd. In this sense, Crowd-Action also encompasses what are commonly labelled crowd-sharing, crowd-sourcing, or collaborative production. These are not separate inventions, but alternative names applied to the same underlying mechanism: pooled commitments passing a threshold to unlock execution.

Crowd-Distribution

Crowd-Distribution applies the Mechanic to route-to-market allocation. In this domain, the population itself forms a distributed network through which goods, permissions, access, information, or authority are routed. Participants act not only as end users but also as local distributors. Tokens may represent purchase commitments, reseller allocations, or access claims, while aggregation rules or thresholds determine how supply is released or allocated across the network. Unlike conventional distribution systems, which rely on centralised retail, wholesale, or institutional gatekeepers, Crowd-Distribution enables opportunities and goods to move through a decentralised social network. Participants may purchase stock for personal use or acquire inventory for local resale, sharing in the rewards of creators. Crowd-Distribution operates as an independent domain of the Crowd-Device. It may be used purely as an alternative route-to-market for existing goods, or it may employ the Crowd-Mechanic to trigger production or allocation thresholds before supply is released. In both cases the crowd itself becomes the distribution infrastructure.

Emergent States and Consequences

↑ Back to Contents

Some Crowd-* terms describe states that arise after a domain has operated. These are not independent domains, but descriptive consequences.

Crowd-Will

Crowd-Will refers to the binding collective decision produced when a threshold is met. It is the recorded result of Crowd-Voting or equivalent participation. Crowd-Will has no force on its own unless execution mechanisms exist.

Crowd-Effect

Crowd-Effect explains the real-world consequences following execution: access changes, delivery of goods, policy shifts, or social outcomes. Crowd-Effect is observable, auditable, and downstream of Crowd-Will.

Derivative and Extended Crowd Expressions

↑ Back to Contents

As the Crowd-Mechanic has spread globally, many additional “crowd” terms have entered common usage. These do not represent new inventions. They are derivative expressions of the same underlying engine, applied to specific objectives. Examples include:

• Crowd-Sourcing — applying the mechanic to ideas, skills, or solutions
• Crowd-Labour — coordinating distributed workforces
• Crowd-Fulfilment — executing delivery through decentralised participants
• Crowd-Allocation — distributing scarce resources via thresholds
• Crowd-Consensus — resolving agreement conditions
• Crowd-Mobilisation — activating populations toward action
• Crowd-Governance — applying the system to civic decision-making

These all use the same token → threshold → outcome structure, regardless of naming, wrapper, or industry. These labels vary by industry, but the underlying engine does not.

Non-Exclusivity Principle

↑ Back to Contents

The four primary domains defined above are not exhaustive. The Crowd-Device was intentionally general. New domains may emerge as society applies the mechanic to new contexts. Such emergence does not diminish authorship or originality. It confirms the breadth of the original invention. The test of novelty lies in the engine, not the label.

Civic Voting vs Elections (important distinction)

↑ Back to Contents

Constitutional voting rights are not prevented or restricted by this definition. Where electoral or civic voting is implemented using the Crowd-Device architecture, such use constitutes an implementation of that system and falls within its scope, irrespective of purpose or context.

This does not constrain the right to vote; it governs the use of a specific participation architecture. Any entity choosing to adopt that architecture does so as an implementation of the Crowd-Device, not as an independent invention.

Illustrative Analogy (Non-Technical)

↑ Back to Contents

• Opportunity Knocks (a historic UK TV talent show) = a paper spreadsheet (manual)
• Crowd-Device = Excel (a systemised Microsoft product)
• Same arithmetic — different systemic capability

Key Differentiating Leaps Introduced by the Crowd-Device

↑ Back to Contents

Prior to the Crowd-Device, threshold-based participation mechanisms existed only within constrained conditions. They were localised, bespoke, domain-specific, and inseparable from their wrapper. Each instance was designed for a single purpose, in a single venue, using a single medium, and dissolved once its outcome was reached. The Crowd-Device did not invent participation. It removed the constraints that prevented participation from becoming a reusable system.

The first leap was the removal of captured isolation. Pre-existing mechanisms were bound to physical presence, local captive audiences, or fixed venues. Participation could not extend meaningfully beyond the immediate environment in which it occurred. The Crowd-Device abstracted participation from location, allowing inputs to be gathered remotely, asynchronously, and at population scale without redesigning the underlying mechanism.

The second leap was the removal of bespoke construction. Previously, every funding effort, vote, petition, or coordinated action required a custom process tailored to that specific purpose. The Crowd-Device separated the participation mechanic from its purpose, creating a single transferable architecture capable of hosting unlimited decisions, without structural modification.

The third leap was the removal of domain confinement. Funding, voting, action, and distribution had historically been treated as distinct systems requiring distinct rules. The Crowd-Device unified them under a single token → threshold → outcome engine, allowing the same participation logic to operate across economic, civic, commercial, and social domains.

The fourth leap was the removal of wrapper dependency. Prior to the Crowd-Device, participation mechanisms were embedded within specific institutional or entertainment formats — elections, game shows, petitions, fundraising drives — each carrying its own rules, legitimacy, and lifecycle. The Crowd-Device separated the participation mechanic from the wrapper itself, allowing the same engine to operate identically whether framed as civic process, entertainment format, commercial platform, or social coordination system.

The fifth leap was the removal of medium dependency. Earlier mechanisms were inseparable from their medium — studio audiences, paper ballots, broadcast shows, or single online platforms. The Crowd-Device made the mechanic wrapper-agnostic, allowing identical operation through paper, broadcast, digital networks, or software without altering the underlying architecture.

What distinguishes the invention is not the geographic scope of deployment, but the abstraction of the participation mechanic into a reusable system rather than a single-purpose construction.

Expressions and Domains

↑ Back to Contents

Medium column: 1 Paper · 2 Broadcast · 3 Online · 4 Software. The examples below illustrate how a single codified participation architecture expresses identically across paper, broadcast, online, and software environments once abstracted into a reusable system; they do not imply exemption from scope, nor do they represent independent inventions.

Inverted Expressions

↑ Back to Contents

Not all uses of the Crowd-Mechanic are benign. Some modern systems deliberately adopt the same structural engine while reversing its custodianship, intent, and safeguards. Inverted systems do not arise independently; they depend upon the prior abstraction, transferability, and scalability introduced by the Crowd-Device. These systems are not independent inventions. They are inversions of the Crowd-Device — using the same token → threshold → outcome architecture, but placing control in the hands of the State or corporate intermediaries rather than the people.

Digital Identity (Digital ID) Systems

Digital ID systems invert the Crowd-Device by transforming identity and behaviour into compulsory tokens. Where the Crowd-Device allowed voluntary participation toward self-chosen objectives, Digital ID systems:

• convert everyday behaviours (movement, spending, health status, speech, associations) into mandatory tokens
• measure those tokens against opaque compliance thresholds
• trigger outcomes that grant or deny access to rights, services, or participation

This is structurally identical to the Crowd-Mechanic, but inverted in custody and purpose. The individual no longer controls the token; the State does. Empowerment becomes control.

Central Bank Digital Currencies (CBDCs)

CBDCs extend this inversion into money itself. By embedding programmable conditions into currency, CBDCs allow:

• behavioural tokenisation of spending
• conditional thresholds on what may be bought, when, and by whom
• automatic execution of sanctions, exclusions, or expiries

This mirrors the Crowd-Distribution and execution layers of the Crowd-Device, but without consent, transparency, or reversion safeguards. What was designed to release funds after collective approval becomes a mechanism to pre-emptively restrict economic life.

Behavioural Control Systems

Behavioural control frameworks — including compliance scoring, risk profiling, and algorithmic eligibility systems — are derivative uses of the Crowd-Mechanic applied coercively. They rely on:

• continuous token capture (behavioural data)
• dynamic thresholding (risk scores, compliance bands)
• automated outcomes (denial, restriction, penalty)

These systems differ only in wrapper from the original engine. The difference is not technical — it is moral and custodial.

Social Credit Systems

Social Credit systems represent the most explicit inversion. They use:

• behavioural tokens
• centrally defined thresholds
• cascading outcomes affecting mobility, finance, speech, and status

Every structural component mirrors the Crowd-Device, but stripped of its safeguards and reoriented toward population discipline rather than collective self-determination.

Why This Is an Inversion, Not a New Invention

↑ Back to Contents

In all cases above:

• the mechanic is identical
• the domains of application are expanded, not invented
• the change lies only in centralisation and enforcement, not structure

The inversion is achieved by removing:

• voluntary participation
• transparent thresholds
• escrow and reversion
• distributed execution
• citizen custodianship

What remains is the same engine, weaponised.

Definitive Distinction

↑ Back to Contents

• Crowd-Device (Original) — People hold the tokens, set the thresholds, and authorise outcomes.
• Inverted Systems — The State or its proxies hold the tokens, conceal the thresholds, and impose outcomes.

This inversion does not break derivation. It proves it.

Role of This Reference Sheet

↑ Back to Contents

This document exists to stabilise meaning across:

• forensic case documents,
• legal filings,
• policy discussions,
• public explanations.

It prevents opponents from fragmenting the invention into “unrelated features” and prevents accidental mischaracterisation through inconsistent terminology.

Closing Statement

↑ Back to Contents

The Crowd-Device is not a trend. It is not a platform. It is not a product of technology. It is a participation engine whose scope has proven far larger than any single application. This reference sheet fixes its language so that the discussion can proceed on substance, not confusion.