Represent what a node can accomplish, not only what it stocks.

Following the evidence review, each business needs three linked representations. Offer covers what a customer can buy: products, services, bundles, packages, appointments and made-to-order items, with prices and availability. Capability covers what the business can do: customise, repair, install, design, source, manufacture, advise, diagnose or maintain, within stated capacity limits. Proof covers why anyone should believe it: identity, credentials, photos, video, completed work, reviews, service-level history and policies.

This is not a case for abandoning catalogues. Structured offer data is still needed for matching, price display, settlement and fulfilment. The point is that the catalogue should stop being the only representation of local commerce.

A sketch of the fields, not a specification illustrative:

node:
  type: service_professional        # an electrician
  service_area_km: 8
offers:
  - service: switchboard repair
    price_band: "₹300–800 per visit, parts extra"
  - service: ceiling fan installation
    price_band: "₹350 per fan"
capabilities:
  - name: residential fault diagnosis
    equipment: [multimeter, thermal camera]
    lead_time: same day
    capacity_per_week: 20
  - name: smart-home device installation
    lead_time: 2 days
proof:
  - claim: business identity
    status: network-verified
    last_checked: 2026-09-10
  - claim: electrical licence
    status: third-party-verified
  - claim: 146 completed jobs
    status: transaction-derived      # counted only from network transactions
  - claim: specialist in old-wiring upgrades
    status: self-declared
fulfilment:
  modes: [appointment, same-day visit]
  escalation_owner: node

Two design choices matter. Every proof entry carries a verification status (the ladder in Shift 6), so the interface can never blur a claim with evidence. And fulfilment is part of the record, because a service business’s promise includes when and how it turns up. Which of these fields ONDC’s current domain specifications can carry, and which would need extensions or new specifications, is a design question for the pilot.

Asking every small merchant to maintain SKUs, capabilities, credentials, availability, capacity, service areas, photos, videos and reviews would recreate the digitisation burden that kept many of them offline in the first place. Many are already partly digital: they accept UPI, use WhatsApp and appear on a map, yet have nothing structured that an agent could query.

The evidence is instructive. In a study of 1,003 small fixed-store merchants in Jaipur, 58% had adopted no digital payment method even though adoption was affordable. Among adopters, 81.4% of transactions were still in cash. The most common reason given was lack of customer demand^[2]. The study is older and concerns payments, not discovery, so it shouldn’t be read as a measure of digital invisibility today. Its lesson is behavioural: merchants digitise when customers ask for it and the workflow fits, not because the tool is cheap.

So the architecture needs a merchant representation layer. It takes very low-friction inputs, such as a WhatsApp message, a voice conversation, photographs, invoices, an existing catalogue, a map or ONDC listing, a short walkthrough video or an assisted onboarding visit. From these it progressively builds offer, capability and proof, with periodic human verification.

Accuracy matters as much as cost. An automatically generated profile that overstates what a merchant can do is worse than no profile, so extraction errors have to be measured by sampling from the start. If representation is expensive, the network never reaches density. If it is cheap and accurate, and improves with every transaction, the network gets richer over time.