Name: Beckn ODR Interface
Title: "Setting up development environment"
Labels: C4GT Community

---

Description

Problem:
Development environment not set up.

Goals
• Development environment should be set up and tested for below requirements.
o Open API 3.0
o JSON Schema
o NodeJS
o JavaScript
o Type Native
o MongoDB
• A basic “Hello World” program to be created and executed successfully.
• Database access and CRUD operations to be performed.
• Any required plugin should be installed and tested.
• Postman to be installed and tested with dummy APIs. (https://dummyjson.com/)

Expected Outcome
• Development environment up and running without any errors.

Acceptance Criteria
• Sample program runs without error.
• Database is accessible and can be used for CRUD operations.

---

Project
Beckn

Organization Name:
Beckn Open Collective

Domain
Others

Tech Skills Needed:
• Basic level software installation
• Basic level programming

Mentor(s)
@faizmagic

Complexity
Low

In the /search path intent.category is used to denote the type of ODR service being availed (Arbitration/Mediation/Conciliation etc), may this be better suited to fulfillment type?

In /on_search, catalog.category is used to denote the field in which the services are being availed (family/commercial/employment etc.)

Name: online-dispute-resolution
Title: "Getting Acquainted with BECKN"
Labels: C4GT Community

---

Description

Goals:
Test out the sandbox APIs from the Postman.
https://github.com/beckn/beckn-sandbox
https://github.com/beckn/beckn-sandbox/blob/main/USER_GUIDE.md

Expected Outcome:
Understanding of BECKN API calls for each user action made on the BAP application.

Acceptance Criteria:
A document explaining the user actions with their corresponding API calls and the sequence diagram of API calls.

---

Project:
Beckn

Organization Name:
Beckn Open Collective

Domain:
Others

Tech Skills Needed:
• Basic understanding of BECKN
• Basic documentation

Mentor(s)
Faiz Mohammed

Complexity
Low

Issue Details:

Problem Statement:

The current folder structure lacks organization for Network Participant's implemented examples, making it challenging to manage and locate specific workflows implemented by NPs.

Proposed Solution:

Update the folder structure to include a dedicated "NP Logs" directory, with subdirectories for each Network Participant. Each NP directory should contain subdirectories for specific workflows (e.g., search, select).

Benefits:

• Improved organization and clarity for NP examples.
• Simplified navigation and maintenance of NP-related workflows.
• Improved Collaboration: Any new Network Participant (NP) joining the project will have ready-made references available on how other NPs have implemented specific use cases.
• Enhanced Documentation: Documenting the logs will contribute to better spec governance, compliance, and transparency. It will also serve as a valuable resource for building test cases for Network Validation.
• Knowledge Transfer and Training: The documented logs can be utilized for training AI models in the future, aiding in the generation of use-case-specific JSONs. This promotes knowledge transfer and ensures a valuable resource for future development.

Current Folder Structure:

• API
• Docs
• Examples

Proposed Folder Structure:

• API
• Docs
• Examples
• NP Logs
  • Network Participant Name
    • search
    • select

Additional Information:

• Consideration for future NPs can be made by creating subdirectories accordingly.
• Ensure backward compatibility with existing examples during the migration.

name: Law & Justice Functional Documentation
title: "Functional Documentation for Legal Services domain"
labels: BOC, PULSE, ODR, Functional Documentation, Law & Justice

Description

In our constant endeavor to provide complete information on the probable implementations for Law and Justice; here is an attempt to summarize the details from various sources and interactions with SMEs.
This document contains all the updated changes such as additional mockups, workflow adjustments, different ideas, and use cases. It also includes API workflows for reference.

Goals

• The goal of this document is to incorporate real-world use cases that is possible in the Legal Services sector
• Capture the workflows for the use cases
• Provide an end to end understanding of what can be achieved in this sector
• Examine how taxonomies are defined (if applicable)

Expected Outcome

The document should provide both functional and technical know-how to the end user. Request the stakeholders and SMEs to review the document and suggest any necessary changes.

Draft document to be reviewed:
https://github.com/viraj89/PULSE-Specification/tree/main/docs/example-implementations/1-ODR

Project Name

[Beckn]

Organization Name:

Beckn Open Collective

Domain

Law and Justice

Skills required

Domain expertise in Law and Justice

Project Details

Beckn protocol is a set of open specifications aimed to create a common language, that is machine-readable and enables interoperability for economic transactions between disparate platforms of any size and form - be it a cab reservation, or booking a stay, or confirming a doctor’s appointment, and many more. Thus it enables the creation of inclusive and equitable open networks offering a multitude of choices to the citizens, while at the same time negating the dependence on intermediaries to freely operate and generate economic transactions of value. It is akin to what SMTP is to E-mails or HTTP is to the Internet.

Since its inception in 2019 as a set of specifications, Beckn has been adopted across geographies in sectors such as mobility, retail, hyperlocal logistics, healthcare, skills, agriculture sectors, etc. Few notable examples of open networks built on the Beckn protocol are Open Network for Digital Commerce (ONDC), Namma Yatri at Bangalore, Kochi Open Mobility Network (KOMN), Unified Health Interface (UHI), etc.

The Beckn ODR Interface is an API that emulates the behaviour of an Open Dispute Resolution Network. BAPs can build rich integrated experiences by combining services offered by multiple BPPs on the network. BPPs can build complex products by analyzing the nature of input from multiple BAPs. This is an important step in the set up and expansion of open networks. Businesses can test their implementations for protocol compliance by plugging into this sandbox.

Features to be implemented

• Beckn-protocol compliant catalogs across multiple dispute resolution services
• BPP endpoints : search, select, init, confirm, status, update, track, cancel, rating, support
• BAP endpoint : on_search, on_select, on_init, on_confirm, on_status, on_update, on_track, on_cancel, on_rating, on_support
• BG endpoint : search
• Registry endpoints : lookup

What exists

• Beckn protocol sandbox at : https://github.com/beckn/beckn-sandbox

What needs to be built

• A fully functioning scalable ODR sandbox compliant to beckn protocol specifications
• A bot that emulates dispute resolution agents for various ODR services

Learning Path

Complexity

Medium

Skills Required

• Open API 3.0
• JSON Schema
• NodeJS
• JavaScript
• TypeScript
• MongoDB

Name of Mentors:

Product Understanding

• @ravi-prakash-v
• @faizmagic
• Keerthana (github username to be added in due course)

Protocol Specification Design

• @ravi-prakash-v

Project Setup and Guidance

• @faizmagic
• @hemant-eminds
• @nikhil2128
• @ujjwal502

Product Setup

• @nikhil2128
• @ujjwal502

Product Architecture

• @ravi-prakash-v
• @nikhil2128

Frontend Development

• @ujjwal502

Backend Development

• @nikhil2128
• @emindsajay
• @zoyaashik

Deployment and Devops

• @prasad-takale-eminds

Testing and QA

• @SushanthKJ

Project size

8 Weeks

Project Setup Guide

To set up this project, please connect with the Project Setup and Guidance mentor for this project and follow their instructions

Product Set Up

To set up this project, please connect with the Product Setup and Guidance mentor for this project and follow their instructions

Acceptance Criteria

• End-to-end simulation of typical ODR use cases on a beckn ODR reference application

Out of Scope

• UI development, (however contributions to existing UI implementations are welcome)

Milestones

• Understanding beckn protocol
• Understanding dispute resolution ecosystem and use cases
• Developing knowledge model for ODR ecosystem
• ODR Knowledge model Adaptation to beckn protocol
• Development of search / on_search API
• Development of select / on_select API
• Development of init / on_init API
• Development of confirm / on_confirm API
• Development of status / on_status API
• Development of update / on_update API
• Development of track / on_track API
• Development of cancel / on_cancel API
• Development of rating / on_rating API
• Development of support / on_support API
• Creation of emulator for ODR agent

Revision of the README file is required. Additions are required in sections such as updating introduction section, Opportunities for the field of Law & Justice, the "About" section, and benefits.

This update is in response to the request received from Meenakshi/Priyanka on November 29.
Source:
https://docs.google.com/document/d/1_9UgnazGvoITmPK6MDn3uajcxj-Bk6BZwDaqfker1U4/edit

Description

As part of this project, we require the developer to develop comprehensive use cases for ODR. These use cases will serve as essential building blocks for the development of the system, outlining its functionalities, user interactions, and expected outcomes. The use cases will play a crucial role in ensuring the project meets its objectives of empowering users to use the app by taking care of all possible outcomes.

Goals

• List down all the different workflow possibilities for ODR.
• For each possibility, come up with a use case and the parameters it depends on.

Expected Outcome

Create a use case document, with all the different different options that are available in the domain, along with the different scenarios in each use case.

Acceptance Criteria

• Create a use case document, with all the different different options that are available in the domain
• Note down the different scenarios in each use case.

Implementation Details

NA for this issue

Mockups / Wireframes

NA for this issue

---

[Please note that the below section of the ticket has to be in the format as mentioned as it is key to enabling proper listing of the project. Please only choose the options mentioned under the headings wherever applicable.]

Product Name

Beckn

Project Name

Beckn ODR Sandbox

Organization Name:

Beckn

Domain

energy

Tech Skills Needed:

[Required technical skills for the project]

Mentor(s)

@shenoyninad

Complexity

Medium

Category

Documentation

Sub Category

API

Name: Pulse Specification
About: The examples are incorrect
labels: ODR, Example JSON, catalog

Description

The examples in the specification dont follow the specification definition. For example, the on_search catalog in this file is not as per the specification.

The message.provider should be inside the message.catalog.

Goals

Make the examples consistent with the specification.

Implementation Details

Go through the JSON examples present in /examples dir
Check if they are consistent with the specification
Fix all the inconsistencies found