ondc-official/pramaan

1. Repository purpose

- This repo is not an application backend or frontend. It is the public asset/documentation repository for Pramaan, ONDC’s integration test bench.

- Its main job is to define and publish protocol test cases, schemas, and usage docs for validating ONDC integrations.

2. Primary architecture boundary

- The core boundary is between Pramaan and external ONDC participants:

- BAP = Buyer App Platform

- BPP = Seller/Provider App Platform

- Pramaan sits as a validation and testing harness around protocol interactions, not as a business workflow system.

3. Documentation layer

- README.md plus the docs/ tree provide the human-facing product and onboarding material:

- introduction

- getting started

- domain/support guidance

- This suggests the repo serves both as a test specification source and a supporting knowledge base.

4. Domain scope

- The only explicit test domain in the tree is retail under testcases/retail/.

- That indicates the repo is organized by ONDC domain/use-case, and retail is one concrete protocol area covered here.

5. Test case organization by participant role

- Retail test cases are split into:

- ret-bap/ for Buyer App side request flows

- ret-bpp/ for Seller/Provider side callback/response flows

- This separation is important: the repo models both sides of the ONDC protocol conversation.

6. BAP schema set

- testcases/retail/ret-bap/ contains schema files for the buyer-initiated workflow:

- context.schema.js

- search, select, init, confirm, update, cancel, track, info

- These files represent the shape and constraints of outgoing protocol messages generated by the Buyer App side.

7. BPP schema set

- testcases/retail/ret-bpp/ contains callback schemas for the provider side:

- context.schema.js

- on_search, on_select, on_init, on_confirm, on_cancel, on_status, on_track, on_info, on_update

- catalog_rejection.schema.js

- These model the asynchronous response/callback contracts expected from the Seller/Provider App.

8. Protocol flow implied by the files

- The schema naming shows the end-to-end transaction lifecycle:

- discovery/search

- selection

- initialization

- confirmation

- order status / tracking / updates

- cancellation / info handling

- Pramaan likely validates each hop independently, ensuring both request and callback payloads conform to ONDC expectations.

9. Implementation style

- The schemas are JavaScript files, which implies the validation layer is likely built around schema modules rather than handwritten prose specs.

- In architecture terms, these are the repo’s machine-readable contract artifacts.

10. Operational and support surface

- .github/workflows/auto-comment-on-issue.yml adds lightweight GitHub automation for issue handling/support.

- That reinforces that the repository also functions as a community/support entry point, not just a spec store.

11. What is not present

- There is no visible application source, service orchestration code, database layer, or deployment manifests in this tree.

- So the repo’s architecture is centered on documentation + test definitions, with the actual Pramaan runtime presumably living elsewhere.

12. How to diagram it

- A good architecture diagram would show:

- ONDC participant apps on both sides

- Pramaan as the test/validation platform in the middle

- retail domain schema artifacts feeding the validator

- docs/support and GitHub issue automation as auxiliary surfaces

- The key flow is protocol messages ↔ schema validation ↔ callback validation ↔ result/support.