Signals (Blue Dots)

A signal — a Blue Dot — is a local expression of intent from a citizen or enterprise. The Signals DPG is the network-aware backend that stores signals as schema-typed items and matches them across instances.

Anatomy of a signal

Every signal is stored as an item: a versioned, schema-typed record. The item_type is always a schema identifier such as profile_1.0 — never freeform text. This guarantees that two instances exchanging signals agree on structure.

Two fields are generated by the backend during item creation and must never be set by clients:

Field	Purpose
item_instance_url	Where the item lives.
item_schema_url	The schema it conforms to.

Seekers and providers

Signals come from two complementary roles:

• A seeker expresses demand — e.g. a youth looking for work of a specific trade.
• A provider expresses supply — e.g. a local employer who needs that exact skill.

The network’s job is to discover and connect compatible seekers and providers that are close in distance but were previously invisible to each other.

Consent is foundational

Consent is foundational

Every signal — every Blue Dot — exists only because the person or organisation it represents chose to publish it. A signal becomes digital, and is then discovered and exchanged across the network, solely by the choice of the seeker or provider behind it. Consent is not an add-on to the model; it is the reason a signal exists at all.

Contact details are shared on connection, not on discovery

Discovery surfaces that a relevant match exists. It does not hand over phone numbers.

Personal contact details are released only once both parties agree to connect — enforced in the network schema itself, where each action interaction declares reveals_pii_on_status, listing the statuses at which PII becomes visible. In the reference blue_dot network that status is accepted, on every interaction.

This is what makes a Blue Dot safe to publish: being discoverable is not the same as being contactable.

How a signal moves through the network

1. Create — a signal is created (directly, by voice, or via an aggregator) and stored as an item in an instance.
2. Discover — the network performs count-first discovery: it asks peer instances how many relevant items they hold, picks only the relevant peers, and fetches just the needed slices.
3. Match — candidate items are merged and scored, and matches are surfaced.
4. Act — an action between two items (e.g. expressing interest) produces an event capturing the structured result.

This count-first, fetch-only-what-matters approach is what lets discovery scale across many instances without every instance querying every other. The implementation detail lives in Read & Write Paths.

Where signals come from

• Direct — a citizen or enterprise creates a Blue Dot through a web or voice interface.
• Voice AI — signals are captured conversationally, in local languages, at a fraction of survey cost.
• Aggregators — organisations bulk-create signals for the participants they onboard, via the Aggregator DPG. Four intake methods ship ready-made: offline camp, bulk upload, outbound campaign and inbound QR campaign.

For the full journey from “who should become a Blue Dot” to a live, verified, discoverable entry, see The Blue Dot Lifecycle.