Skip to content
Blue Dots EconomyBlue Dots EconomyDocumentation

Steps of Deployment

This is the recommended path for a new adaptor: an organisation deploying Blue Dots for a district, state or domain. The steps are the same for every domain, such as jobs (Blue Dot) or education (Yellow Dot). It assumes you have read Blue Dots as a DPG.

The path at a glance

Section titled “The path at a glance”
1
Stand up Signals

Start with the Signals backend: get the Signals API and UI running against local Postgres + Redis.

2
Define domain + participant types

Decide the domain you participate in and the participant types your instance serves, expressed as schemas and SERVED_DOMAINS config.

3
Add Aggregator

Add the Aggregator DPG to onboard many partner organisations, writing participant profiles and listings through the bulk-create paths.

4
Add capture channels

Web (the schema-driven Signals UI and the Aggregator portal), plus Voice AI for low-cost sign-up by phone in the local language.

5
Integrate notifications

Wire SMTP (email) and an SMS provider for OTP, confirmations and match notifications.

6
Pilot & measure

Run a bounded pilot in one district and track the before and after measures agreed for the sector.

Step 1: Stand up Signals

Section titled “Step 1: Stand up Signals”

Start with the Signals backend. Follow Signals DPG Setup. At the end you should have the Signals API and UI running against local Postgres + Redis.

Step 2: Define your domain and participant types

Section titled “Step 2: Define your domain and participant types”

Decide the domain you participate in and the participant types your instance serves. The code calls a domain a network, and its domains field and SERVED_DOMAINS list participant types. For example, the jobs domain blue_dot has the participant types seeker and provider, and the education domain (Yellow Dot) has student and tutor/counsellor. See Domains, Participant Types and Instances for every domain. Because the model is schema-driven, you express these as schemas and SERVED_DOMAINS config, not code. Define your item types (e.g. profile_1.0) up front.

Step 3: Add the Aggregator DPG

Section titled “Step 3: Add the Aggregator DPG”

When you are ready to onboard many partner organisations, add the Aggregator DPG. Configure it to write participant profiles and listings into your Signals instance through the bulk-create paths, signing in with a Keycloak service account:

authorization: Bearer <client-credentials token>
x-acting-org-id: <the organisation you act as>

Register a confidential Keycloak client whose client id equals your organisation’s slug, then add it to KEYCLOAK_SERVICE_CLIENT_IDS on the Signals API. The list is empty by default, so a new DPG is refused until it is listed. See Keycloak Setup.

Step 4: Add capture channels

Section titled “Step 4: Add capture channels”
  • Web: the schema-driven Signals UI and the Aggregator portal.
  • Voice AI: low-cost capture by phone call in the local language. A voice DPG connects the same way an aggregator does (Keycloak service account and bulk create). Ready-made prompt sets for the jobs domain are published as DPGs; see AI Voice Agent Prompts.

On the assisted route, pick the intake method per campaign: offline camp, bulk upload, outbound campaign or inbound QR campaign. All four ship ready-made; see The Blue Dot Lifecycle.

Step 5: Integrate notifications

Section titled “Step 5: Integrate notifications”

Wire SMTP (email) and an SMS provider for OTP, confirmations and match notifications. Mailpit covers email locally.

Step 5b: Make it yours

Section titled “Step 5b: Make it yours”

Branding, operational settings, dashboards and a public landing page are configuration and presentation layers. None of them needs changes to the Signals or Aggregator code. See Customisation & Branding.

Step 6: Pilot and measure

Section titled “Step 6: Pilot and measure”

Run a bounded pilot in one district and track before and after metrics. The jobs pilots in Ghaziabad and Dharwad tracked jobs found, time to find a match, cost per interaction and conversion; other domains pick measures for their own sector. See Pilots.

Onboarding checklist

Section titled “Onboarding checklist”
  • Signals API + UI running, migrations applied.
  • Domain network.json and SERVED_DOMAINS defined; item types registered.
  • Keycloak realm imported; admin user created.
  • Aggregator DPG deployed.
  • Service client registered (id = org slug) and listed in KEYCLOAK_SERVICE_CLIENT_IDS.
  • SMTP + SMS providers connected.
  • S3 bucket + credentials provisioned for bulk upload.
  • Branding applied (brand.json, UI theme, Keycloak login theme).
  • Route in (assisted / self) and intake method chosen per campaign.
  • Pilot scope and impact metrics agreed.

Where to go next

Section titled “Where to go next”