> For the complete documentation index, see [llms.txt](https://india-energy-stack.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://india-energy-stack.gitbook.io/docs/pathways/tsp.md).

# Technology Service Provider Pathway

This guide is for **AMISPs (Advanced Metering Infrastructure Service Providers), meter / EV-charger / inverter OEMs, system integrators, and analytics vendors** — the organisations that typically **build the IES adapter on behalf of a DISCOM client**, or whose products need to interoperate with many DISCOMs at once.

Unlike the [**Utility Pathway**](/docs/pathways/utility.md) (written from the DISCOM's point of view), you are usually the one writing the mapping code, wiring the handler, and testing the payload — for a client who owns the identity but not the engineering effort. And if your product serves more than one DISCOM, you may need an identity of your own for the parts of the flow where you sign or participate in your own right. Expand any step for guidance, prework checkpoints, and the exact schema you'll map against.

***

## Roadmap Overview

```mermaid
flowchart TD
    understand["Phase 1: Understand What You Are Building (Step 1.1 - 1.2)"] --> mapping["Phase 2: Map Your Product Data Model (Step 2.1 - 2.2)"]
    mapping --> identity["Phase 3: Register Your Own Entity (Step 3.1 - 3.2)"]
    identity --> conformance["Phase 4: Conformance Testing Across Deployments (Step 4.1 - 4.2)"]
```

***

## Prework & Pre-Alignment Matrix

Align these internal roles before starting. Because a TSP typically serves several DISCOM clients, organise them **per product line**, not per client engagement:

| Department / Role                   | System / Resource Involved                                 | Purpose in Pathway                                                                                                               |
| ----------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Integration / Field Engineering** | HES, MDM, meter firmware, inverter/charger telemetry stack | Owns the Part-2 mapping — the only code a vendor actually writes                                                                 |
| **Product / Platform Architecture** | Multi-tenant deployment topology                           | Decides whether the product needs its own `did:web` or configures inside each client's deployment                                |
| **IT & Security Admin**             | Cloud KMS / HSM, Docker environments                       | Secures signing keypairs where the TSP itself signs credentials (e.g. `MeterDataCredential`)                                     |
| **Client Success / Delivery**       | DISCOM client contracts, SLAs                              | Coordinates which DISCOM-owned identifiers (their `did:web`, their DeDi namespace) the product configures against per deployment |

***

## Phase 1: Understand What You Are Building

Before writing any code, get clear on the shape of the system you are integrating with, and which part of it is actually your job to build.

<details>

<summary>Step 1.1: Learn the Register / Discover / Exchange Spine</summary>

### 💡 Phase Advice

> Read the three spine pages once before opening any schema — most week-one vendor questions map to one of the three.

### Execution Guidance

IES organises every interaction into three steps:

1. [**Register**](/docs/concepts/setup-register/register.md) — verifiable digital identity (`did:web`) and the shared directory (DeDi). See [**Setup Register**](/docs/concepts/setup-register.md).
2. [**Discover**](/docs/concepts/setup-exchange/discover.md) — Beckn-protocol interaction between systems. See [**Setup Exchange**](/docs/concepts/setup-exchange.md).
3. [**Exchange**](/docs/concepts/setup-exchange/exchange.md) — schemas, taxonomy, and verifiable credentials. See [**Build your Internal-facing Adapter**](/docs/concepts/build-adapter.md).

Register and Discover usually belong to your DISCOM client. **Exchange — the Part-2 mapping — is your team's work.**

### References & Anchors

* [Getting Started — how IES works: Register, Discover, Exchange](/docs/readme.md#how-ies-works-register-discover-exchange)
* [Register](/docs/concepts/setup-register/register.md)
* [Discover](/docs/concepts/setup-exchange/discover.md)
* [Exchange](/docs/concepts/setup-exchange/exchange.md)
* [Before you build — the Concepts overview](/docs/concepts/how-you-implement-ies.md)

</details>

<details>

<summary>Step 1.2: Understand the Two-Part Adapter, and Which Part Is Yours</summary>

### 💡 Phase Advice

> Tell your client: *"Your systems don't change. A small adapter sits at each system's edge, in two parts: a ready-made part — Beckn ONIX — that finds other systems and exchanges messages, which you don't build; and a mapping between your data formats and the IES specs, which you do."* That second part is what you're hired to build.

### 📋 Prework Required

* Confirm with your client which system(s) — HES, MDM, DERMS, billing — you will be reading from or writing to for the mapping.
* Confirm whether your client already has ONIX (Part 1) deployed, or whether that deployment is also in your scope.

### Execution Guidance

1. **Part 1 — the engine (ready-made).** One engine per capability: **ONIX** for Beckn-network use cases (discovery, messaging, signing, routing) and **OpenCred** for credential use cases (issue, verify, revoke). You configure and deploy these, not build them.
2. **Part 2 — your mapping (what you build).** The translation between your (or your client's) data format and the IES schema shapes, feeding the engine. Vendors build to one published standard, not a fresh custom integration per client. For a single use case this is typically 200–1,000 lines of code.
3. Scope your engagement around Part 2; treat Part 1 (if in scope) as a one-time infrastructure task, not ongoing cost.

### References & Anchors

* [Build your Internal-facing Adapter — what the adapter is](/docs/concepts/build-adapter.md#what-the-adapter-is)
* [Before you build — the Concepts overview](/docs/concepts/how-you-implement-ies.md)

</details>

***

## Phase 2: Map Your Product Data Model to the Relevant IES Schema

This is the core of the engagement: translating your product's native data model into the compact profile shapes or credential fields IES expects.

<details>

<summary>Step 2.1: AMISPs — Map HES/MDM Output to MeterData v0.6</summary>

### 💡 Phase Advice

> Work profile-by-profile. Most integrations need only a subset of the eight — pull what `MeterDataRequest` asks for.

### Execution Guidance

An AMISP typically maps its HES/MDM output into the **MeterData v0.6 compact profiles**:

| Profile         | What it carries                                                                       |
| --------------- | ------------------------------------------------------------------------------------- |
| `CUSTOMER`      | Slow-changing customer metadata, service points, meter installations                  |
| `INTERVAL`      | Block load survey at high-resolution intervals (15 or 30 min)                         |
| `DAILY`         | Daily accumulated load survey profiles                                                |
| `MONTHLY`       | Monthly billing resets — ToU buckets, MD, cumulative registers                        |
| `BILL_DETAILS`  | Computed billing details — amount, due date, payment status                           |
| `INSTANTANEOUS` | Real-time snapshot of voltages, currents, powers                                      |
| `EVENT`         | IS 15959 diagnostic codes and tamper events                                           |
| `ALARM`         | Active alerts — tamper, low prepayment balance, voltage sag, power threshold exceeded |

1. **Map fields**: map each profile to its HES/MDM export field (DLMS-COSEM registers, IEC 61968-9 interval data, etc.) — this table *is* your Part-2 spec.
2. **Respond to `MeterDataRequest`**: your BPP handler must return only the requested resources, profiles, and time window.
3. **Sign, where required**: wrap payloads needing provenance attestation in a **MeterDataCredential** rather than delivering them bare — see Step 2.2 and Phase 3.

### References & Anchors

* [MeterData schema page](/docs/schemas/meterdata.md)
* [MeterData v0.6 Schema Reference](https://india-energy-stack.gitbook.io/docs/schemas/meterdata/v0.6)
* [Build your Internal-facing Adapter](/docs/concepts/build-adapter.md)

</details>

<details>

<summary>Step 2.2: OEMs — Map Device Attributes into ElectricityCredential energyResources</summary>

### 💡 Phase Advice

> Pick the narrowest correct `energyResources[]` kind for your device rather than a generic one — a solar inverter is `EnergyResourceInverter`, not `EnergyResourceGenerator`. Getting the discriminator right avoids a later schema migration.

### Execution Guidance

A DER/EV-charger/inverter OEM populates the relevant kind in `energyResources[]` in **ElectricityCredential v1.2**:

| `energyResources[]` kind  | Device types                                              | Underlying standard                              |
| ------------------------- | --------------------------------------------------------- | ------------------------------------------------ |
| `EnergyResourceGenerator` | `SOLAR_PV`, `WIND`, `HYDRO`, `BIOGAS`, `CHP`, `FUEL_CELL` | `cim:GeneratingUnit` subtypes (IEC 61970-302)    |
| `EnergyResourceStorage`   | `BESS`                                                    | `cim:BatteryUnit` (IEC 61970-302)                |
| `EnergyResourceEVCharger` | `EV_CHARGER`, `EV_V2G`                                    | `cim:ElectricVehicleChargingStation` (CIM17+)    |
| `EnergyResourceInverter`  | `INVERTER`                                                | `cim:PowerElectronicsConnection` (IEC 61970-302) |

1. Each entry is discriminated by `type` into one of these kinds, with a typed `attributes` bag per device class.
2. Power/capacity fields use `QuantitativeValue { value, unit }` with short unit aliases (`kW`, `kWh`, `kVA`, `kVAR`, `kV`, `MW`, `MWh`, `MVA`, `MVAR`, `V`, `W`).
3. Compose the identifier as a `did:web` path under the **issuing DISCOM's** domain (e.g. `did:web:<discom-domain>:assets:meter:<meter-serial-no>`), preserving serial numbers verbatim — see [Identifier patterns](/docs/concepts/setup-register/register.md#identifier-patterns).
4. The credential is signed by the DISCOM, or by whoever is the actual issuer if you operate signing infrastructure on their behalf — see Phase 3.

### References & Anchors

* [ElectricityCredential schema page](/docs/schemas/electricitycredential.md)
* [ElectricityCredential v1.2 Schema Reference](https://india-energy-stack.gitbook.io/docs/schemas/electricitycredential/v1.2)
* [Build your Internal-facing Adapter](/docs/concepts/build-adapter.md)

</details>

***

## Phase 3: Register Your Own Entity if You Serve Multiple DISCOMs

If you operate a multi-DISCOM platform — for example, an AMISP running metering infrastructure for five different DISCOMs — you need to think about **two separate identity layers**, not one.

<details>

<summary>Step 3.1: Decide Whether You Need Your Own did:web</summary>

### 💡 Phase Advice

> Don't assume a separate deployment per client is enough — if your platform ever signs a credential or publishes a catalogue as a Beckn participant, it needs its own identity.

### ⚠️ Caution

> Conflating your platform's identity with a client's `did:web` breaks the trust chain: `issuer.id` must resolve to whoever actually signed the payload, or verification and audit break down.

### Execution Guidance

Each DISCOM client keeps its own `did:web` and identity. But a TSP acting as a **Beckn network participant in its own right** — e.g. publishing a catalogue or signing a `MeterDataCredential` as the **"provider"** — needs its **own `did:web` and Beckn subscriber registration**.

The `MeterDataCredential` schema names the issuer as a **data provider (e.g. AMISP, MDM, DISCOM)** — a role that can be distinct from the DISCOM. If you sign as that provider, you — not your client — need the identity below.

1. Pick a domain your organisation controls (not a client's domain).
2. Follow the same identity setup as any other participant: publish a `did.json`, generate a signing keypair, and claim your own DeDi namespace.
3. Keep identities distinct per product line — don't reuse one signing key across unrelated product lines.

### References & Anchors

* [Register](/docs/concepts/setup-register/register.md)
* [Register — The registries IES uses, by role](/docs/concepts/setup-register/register.md#the-registries-ies-uses-by-role)
* [MeterDataCredential schema page](/docs/schemas/meterdatacredential.md)

</details>

<details>

<summary>Step 3.2: Set Up Your Own DeDi Namespace and Register with IES</summary>

### 💡 Phase Advice

> Use an institutional role-mailbox for your namespace admin, not a named employee's account — your platform's identity will outlive any one engineer.

### Execution Guidance

1. Follow [**Setup Register**](/docs/concepts/setup-register.md) to publish `did.json`, generate a signing keypair, and claim a DeDi namespace.
2. Create your own subscriber registries (`subscribers-test`, `subscribers-prod`) if participating directly as a provider — see [**Setup Register §1.6**](https://india-energy-stack.gitbook.io/docs/pathways/pages/x4JXc2x9ljke9mGdzMbp#id-1.6-beckn-participants-publish-your-beckn-subscriber-record).
3. Apply for an IES listing like any participant: send your identifier, DeDi namespace, and subscriber registry details to the Secretariat — see [**How to apply for an IES listing**](https://india-energy-stack.gitbook.io/docs/pathways/pages/x4JXc2x9ljke9mGdzMbp#id-1.7-beckn-participants-get-referenced-into-an-ies-network).

### References & Anchors

* [Setup Register](/docs/concepts/setup-register.md)
* [Registries and Directories](/docs/concepts/setup-register/register.md#the-directory-dedi)
* [How to apply for an IES listing](https://india-energy-stack.gitbook.io/docs/pathways/pages/x4JXc2x9ljke9mGdzMbp#id-1.7-beckn-participants-get-referenced-into-an-ies-network)

</details>

***

## Phase 4: Conformance Testing Across Deployments

The payoff of building to one published standard: test your mapping once per product line, and it works unmodified across every DISCOM client — rather than re-testing per client.

<details>

<summary>Step 4.1: Test Once Per Product Line, Not Once Per Client</summary>

### 💡 Phase Advice

> Resist spinning up a bespoke conformance pass per new DISCOM client. Vendors build to one published standard — if your mapping is correct against the schema, it's correct for every client whose data maps to it.

### Execution Guidance

1. Run the conformance checklist against your product's mapping using a sandbox or test counterparty, not every client deployment.
2. Validate your mapped output against the canonical JSON Schema for whichever profile or credential you produce (`MeterData`, `MeterDataCredential`, `ElectricityCredential`).
3. Confirm signatures verify end-to-end, using whichever identity is the actual signer (the client DISCOM's `did:web`, or your own, per Phase 3).
4. Once your product line passes conformance, onboarding a new client should require only configuration — pointing Part-2 mapping at their data source and identity — not new code.

### References & Anchors

* [Conformance Checklist](/docs/concepts/conformance.md)
* [Build your Internal-facing Adapter](/docs/concepts/build-adapter.md)

</details>

<details>

<summary>Step 4.2: Re-Verify Only What Changes Per Client</summary>

### 💡 Phase Advice

> Keep a checklist of what's genuinely client-specific (`did:web`, DeDi namespace, service area, tariff/code lookups) versus what's universal to your product (the schema mapping). Only the first needs a per-client re-check.

### Execution Guidance

Per new DISCOM client, re-confirm only:

1. The client's `did:web` resolves and their signing key is current.
2. The client's DeDi namespace and subscriber registry are correctly referenced in your deployment config.
3. Any client-specific code or tariff-category lookups are correctly wired into your Part-2 mapping's translation tables.
4. One realistic record exchanges end-to-end with that specific client's sandbox before going to production.

### References & Anchors

* [Conformance Checklist](/docs/concepts/conformance.md)
* [Setup Register](/docs/concepts/setup-register.md)

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://india-energy-stack.gitbook.io/docs/pathways/tsp.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.