v2.0 LTS Release: Catalog APIs, CN/PN renaming, fabric positioning, and first batch of docs

[ravi-prakash-v]

Summary

This PR publishes the Beckn Protocol v2.0 normative specification for the first time — introducing the a first set of RFC documents set alongside API and terminology changes in beckn.yaml.

• First publication of NFH-001 through NFH-013 — the normative RFC set defining Beckn Protocol v2.0.
• Catalog infrastructure — new fabric API - Cataloging Service endpoint group added to beckn.yaml
• Terminology — BAP/BPP renamed to Consumer Node (CN) / Provider Node (PN) throughout
• Signature model — CounterSignature in the Ack body replaced by a Signature response header
• Fabric model — establishes the canonical positioning: nodes form the fabric; it has no central host

Note: Some RFC IDs may be missing in the docs. They are currently under review in the draft branch.

RFC document set (first publication)

RFC	Title
NFH-001	Specification: Architecture, Design Philosophy and Principles
NFH-002	Keyword Definitions
NFH-006	Beckn API Endpoints
NFH-007	Authentication and Trust
NFH-010	RFC Authoring Guide
NFH-011	RFC Template
NFH-012	Schema Design Guide
NFH-013	Beckn Communication Protocol

API changes (api/v2.0.0/beckn.yaml)

• Catalog endpoint group: POST /catalog/publish, POST /catalog/on_publish, POST /catalog/push, POST /catalog/subscription, POST /catalog/pull, POST /catalog/on_pull, POST /catalog/search
• CounterSignature removed: Signature response header added to all synchronous responses for transport-layer response authentication
• CN/PN naming: BAP/BPP actor names updated throughout; wire-level field names (bapId, bapUri, bppId, bppUri) retained for backward compatibility
• DiscoverAction: text_search / textSearch removed; publishDirectives removed from Catalog schema
• Catalog search: generalised from /catalog/master/search to /catalog/search with a type filter (default: MASTER)

Test plan

• api/v2.0.0/beckn.yaml validates as valid OpenAPI 3.1.1
• All catalog endpoint paths in READMEs match paths in beckn.yaml
• grep -rn "CounterSignature" docs/ api/ → 0 results
• grep -rn "\bBAP\b\|\bBPP\b" api/v2.0.0/beckn.yaml → 0 results (wire-level field names excepted)
• All links in docs/README.md resolve to files present in docs/

[nirmay]

PR #168 — Code Review

v2.0 LTS Release: Catalog APIs, CN/PN renaming, fabric positioning, and first batch of docs

---

Overview

This is a large, multi-vector change that touches governance, the core YAML specification, and introduces the first normative RFC set. The overall direction is correct and the design improvements are meaningful, but there are several spec-level inconsistencies and one semantic error that need resolution before merge.

---

Governance & Process Documents

GOVERNANCE.md (+347 lines)

• The reference to NFH-005 Design Guide throughout GOVERNANCE.md needs verification — NFH-005 is not in the RFC set being published (the list goes 001, 002, 006, 007, 010–013). If NFH-005 is the Design Guide, it should either be published in this PR or the reference should use its filename path instead of the RFC ID.

---

beckn.yaml — API Changes

Issues requiring fixes:

1. context.try scope is contradicted in three places.

   • beckn.yaml info description (new): "This field is applicable to update / on_update and cancel / on_cancel endpoints ONLY."
   • README.md (unchanged, line 686): "context.try supports sandbox-style operation for applicable flows such as update, cancel, rate, and support."
   • The docs (NFH-013 / Communication Protocol) at line 5767: "including update, cancel, rate, and support."

   These must be consistent. If rate/support no longer support context.try, both the README and the NFH docs need updating.

2. DiscoverAction schema description contradicts the schema itself.
   The schema description says: "The legacy text_search property is retained for backward compatibility."
   But the schema removes both text_search and textSearch (lines 3061–3066 of diff). This is a copy-paste leftover that will confuse implementers. Fix the description to say they were removed.

3. 409 mapped to NackBadRequest in /catalog/subscription POST.
   At the subscription duplicate-detection case:

   '409':
     $ref: '#/components/responses/NackBadRequest'

   HTTP 409 Conflict is semantically distinct from 400 Bad Request. The request is well-formed; the conflict is a state problem. This should either reference a NackConflict response (if one exists or is added) or at minimum use NackBadRequest with a clear description override explaining the conflict reason.

4. /catalog/push uses AuthorizationHeader instead of CallbackAuthorizationHeader.
   This endpoint represents the CS calling the DS — it is a callback, not a client-initiated action. The diff shows AuthorizationHeader on this path. If CallbackAuthorizationHeader enforces the request-chain signing, it should be used here too, consistent with all other on_* endpoints.

5. AckSignatureHeader is added to only a subset of responses.
   The PR description states every synchronous response carries the Signature header. The header component is defined and the docs (NFH-007, line 6102) say "Every synchronous HTTP response — regardless of status code (200, 400, 401, 409, 429, 500) — MUST carry a Signature response header." However, the diff only adds AckSignatureHeader to 5–7 response entries (Ack, NackBadRequest, etc.) via the responses section. The full set of response definitions should be audited to ensure completeness against this normative requirement.

---

Docs (RFC Set)

• The docs directory also contains files numbered 14–25 (Discovery Architecture, Catalog Publishing Service, Payments, JSONld Context, etc.) that are not mentioned in the PR description. These appear to be unreleased drafts committed alongside the published RFC set. Either include them in the PR scope or move them out to avoid confusion about what is normative in this release.
• Internal cross-references use NFH-005 (Design Guide) extensively in GOVERNANCE.md, but this RFC is not part of the published set. If it exists on draft branch, reference by filename; if not published, note it as forthcoming.

---

Summary

The design direction is correct and the governance rewrite is a significant improvement. The five issues above (especially the context.try contradiction, the textSearch description error, and the 409 → NackBadRequest semantic mismatch) should be fixed before merge. The breaking changes list should be documented explicitly.

@ravi-prakash-v

[nirmay]

Deep Review: NFH-007 (Authentication_and_Trust.md) & NFH-013 (Communication_Protocol.md)

---

NFH-007 — Authentication and Trust

Issue 1 — {bap_signature_value} is old BAP terminology throughout §3.3, §6, and examples

[Authentication_and_Trust.md:251, 255, 337, 339, 383](docs/Authentication_and_Trust.md) — the placeholder name {bap_signature_value} appears 5 times in §3.3 (the signing string definition), §6 (the PN callback signing procedure), and Step 7. The document has adopted CN/PN throughout — this is the only place where BAP terminology leaks into the specification text.

Fix: Rename to {cn_signature_value} consistently across §3.3, §6, §7.

---

Issue 2 — Examples use old bap.example.com / bpp.example.com identifiers

[Authentication_and_Trust.md:505, 528, 529, 569, 607, 608, 616](docs/Authentication_and_Trust.md)

All three examples use bap.example.com as the CN namespace and bpp.example.com as the PN namespace. These are old BAP/BPP identifiers. Should use cn.example.com and pn.example.com (or similar) for consistency with the document's own CN/PN terminology.

---

Issue 3 — Two broken cross-references

[Authentication_and_Trust.md:16, 648–649](docs/Authentication_and_Trust.md)

The document references two files that do not exist in the published docs set:

• ./Identity_and_Addressing.md — referenced in Document Details and References. Not published in this PR; not in docs/.
• ./Error_Codes.md — referenced in References. Not published in this PR.

These will produce dead links immediately upon merge. Both references should either link to the correct published filenames or be removed with a "forthcoming" note.

---

NFH-013 — Communication_Protocol.md

Issue 4 — §3 contains a stale "counter-signature SHOULD" line — directly contradicts NFH-007 MUST

[Communication_Protocol.md:155](docs/Communication_Protocol.md):

"Successful acknowledgements SHOULD carry a counter-signature from the receiving node to strengthen non-repudiation. The sending node SHOULD verify the counter-signature where provided."

This line is a pre-PR holdover. The PR explicitly removes CounterSignature and replaces it with the mandatory Signature response header. NFH-007 CON-004-02 says: "Every Beckn HTTP synchronous response MUST carry a Signature response header" — a MUST, not a SHOULD. Using "counter-signature" (removed concept) and "SHOULD" (weaker requirement) here directly contradicts NFH-007.

Fix: Replace with: "Every synchronous response MUST carry a Signature response header as defined in NFH-007 §5. The sending node MUST verify this header."

---

Issue 5 — Conformance table numbering is out of order

[Communication_Protocol.md:438–440](docs/Communication_Protocol.md)

The conformance IDs in the table appear as:
01 → 02 → ... → 19 then 24, 25, 20, 21, 22, 23

CON-013-24 and CON-013-25 (DS aggregation and paginated callbacks) appear before CON-013-20 through CON-013-23 in the printed table. The IDs are correct, but the ordering in the table is wrong. Implementers generating conformance reports against this table will have a confusing read order.

Fix: Reorder the last 6 rows to CON-013-20, CON-013-21, CON-013-22, CON-013-23, CON-013-24, CON-013-25.

---

Issue 6 — Example 1 Ack body uses wrong schema structure

[Communication_Protocol.md:493–505](docs/Communication_Protocol.md)

The synchronous Ack example shows:

{ "message": { "ack": { "status": "ACK" } } }

But beckn.yaml defines the Ack response body as:

message:
  status: ACK     # top-level in message
  messageId: ...

The message.ack.status nesting doesn't exist in the schema. An implementer coding against this example will build the wrong structure. The correct form is message.status: "ACK" (plus message.messageId).

---

Issue 7 — Terminology split: "PN-initiated callback" vs "provider-initiated notification"

NFH-013 uses "PN-initiated callback" throughout (definition in §Definitions, §8 header, conformance CON-013-13/14).

NFH-007 uses "provider-initiated notification" throughout (§3.3, §4 table, §10.3, conformance CON-004-12, CON-004-19, CON-004-20).

These are the same concept but with different names across the two RFCs. Implementers reading both will see two terms with no indication they're the same thing.

Fix: Pick one term and use it in both documents. Add a note in whichever document changes: "Also called [other term] in [other RFC]."

---

Issue 8 — Three broken/provisional cross-references

[Communication_Protocol.md:17, 167, 462, 635–636](docs/Communication_Protocol.md)

• ./Error_Codes.md (NFH-008) — referenced in References section. Not in the published docs set.
• ./Independent_Workflows.md (NFH-TBD) — referenced three times in the body text and References. Labeled "(under draft)" which is honest, but the link will 404. Should add <!-- file not yet published --> or remove the clickable link and keep it as a plain-text reference.

---

Cross-document Inconsistency

Issue 9 — context.try scope: README vs NFH-007 info description vs NFH-013

This was flagged in the broader review but it runs through all layers: README.md (unchanged) and NFH-013 §5 FAQ say context.try applies to update, cancel, rate, and support; beckn.yaml info description says it applies to update and cancel ONLY. NFH-013 also says "including update, cancel, rate, and support" at line 5767 of the diff. One of these is the ground truth; the other two must be corrected.

[ravi-prakash-v]

Thanks Nirmay. Walking through the list.

context.try scope. beckn.yaml ("update and cancel ONLY") is canonical. README.md and docs/API.md updated to match. NFH-013 has no context.try mention; I couldn't locate the diff-line-5767 passage you cited. If you can point me at the rendered line, I'll take another look.

DiscoverAction description. Fixed. text_search and textSearch are now described as removed; structured inputs live under intent.

AckSignatureHeader on the full response set. Good catch. NackForbidden and NackNotFound moved off plain SignatureHeader. All response components are now consistent with CON-004-02.

Catalog items (/catalog/subscription 409, /catalog/push AuthorizationHeader). Leaving these for @anandp504 since they are catalog-specific design calls. Pinged him in a separate comment below.

NFH-007. {bap_signature_value} renamed to {cn_signature_value} in §3.3, §6, §7. §9 examples now use cn.example.com and pn.example.com. Broken refs to Identity_and_Addressing.md and Error_Codes.md retargeted to the draft branch with a "drafted, undergoing review" note.

NFH-013. Stale "counter-signature SHOULD" in §3 replaced with MUST language tied to NFH-007 §5. Conformance table reordered to CON-013-01..25 sequential. Example 1 Ack body now matches the Ack schema in beckn.yaml (no nested ack wrapper). Error_Codes.md and Independent_Workflows.md links retargeted to the draft branch.

Callback terminology. Went with PN-initiated callback as canonical (already the term in NFH-013). provider-initiated notification renamed throughout NFH-007 and the OpenAPI doc, including the §10.3 heading and CON-004-12/19/20.

GOVERNANCE.md. Two issues, both fixed. NFH-006 was being used to mean "RFC writing guide", but per docs/README.md NFH-006 is the API endpoints doc. Retargeted: "RFC template" references to NFH-011 (RFC_Template.md), "RFC writing guide" references to NFH-010 (RFC_Authoring_Guide.md). NFH-005 (Design Guide) is not in this PR's set; links kept in place, URL switched to the draft branch with a forthcoming note.

On "docs/ contains files numbered 14-25": I can't reproduce this. docs/ on core-v2.0.0-lts-rc3 has only the ten files listed in the PR description. Nothing in the 14-25 range. You may have been on the draft branch.

Repushed. Take another pass when you get a chance.

[ravi-prakash-v]

@anandp504, do take a look at these two catalog-endpoint items from Nirmay's review:

1. /catalog/subscription POST returns 409 but currently maps to NackBadRequest (api/v2.0.0/beckn.yaml:1689). Worth considering a NackConflict response, or adjusting the description.
2. /catalog/push uses AuthorizationHeader (api/v2.0.0/beckn.yaml:1567). The other callback endpoints use CallbackAuthorizationHeader; wanted your view on whether to align.

Let me know how you'd like to handle these.

[nirmay]

All issues raised earlier are fixed. although, I cannot find Anand's notes that you wanted me to review.

Authentication_and_Trust.md lines 463–464:
| CON-004-19 | A PN PN-initiated callback MUST carry a unique messageId. | MUST |
| CON-004-20 | A PN PN-initiated callback MUST carry a transactionId... | MUST |
The fix renamed "provider-initiated notification" to "PN-initiated callback" but didn't restructure the sentence, producing "A PN PN-initiated callback." This reads as two nouns colliding.

Fix: Change to: "A PN sending a PN-initiated callback MUST carry a unique messageId." (matching the style of CON-013-13 in NFH-013).

@ravi-prakash-v pls fix a minor nit.

[anandp504]

Addressing the two review comments — PR #169

Both items raised have been addressed in #169:

1. /catalog/subscription POST 409 → NackConflict

Good catch — the 409 was incorrectly mapped to NackBadRequest. A duplicate subscription (identical networkIds+schemaTypes already active for the same subscriber) is a state conflict, not a malformed request. NackBadRequest's description ("structurally invalid or fails semantic validation") doesn't fit this semantics.

Fix: Introduced a new NackConflict schema and response component, following the same pattern as NackForbidden, NackNotFound, etc. The 409 response on /catalog/subscription POST now references NackConflict, and the description text is updated to match.

2. /catalog/push uses AuthorizationHeader — this is intentional and correct

The distinction between the two header types is:

• CallbackAuthorizationHeader uses CallbackSignature, which includes request-signature — the Base64 signature from the triggering CN request. This proves the callback is a genuine response to a specific prior request.
• AuthorizationHeader uses the standard Signature, for requests that are not responses to a prior request.

/catalog/push is a CS-initiated push triggered by a subscription match. There is no originating DS request whose signature could be chained. This makes it semantically a PN-initiated notification, which is exactly the use case AuthorizationHeader is designed for (its description says: "Beckn HTTP Signature authentication header for CN requests and PN-initiated notifications").

Changing to CallbackAuthorizationHeader would be incorrect — the CS would have no request-signature to include in the signing string.

Fix: Added an explicit "Authentication note" paragraph to the /catalog/push description explaining this reasoning, so future readers don't have the same question.

[nirmay]

Review Notes — PR #168 Remaining Issues

---

api/v2.0.0/beckn.yaml

Y-1 — /catalog/push uses AuthorizationHeader instead of CallbackAuthorizationHeader (line 1564)

/catalog/push is a CS→DS push callback — the endpoint description says "The CS signs the request and delivers it to the DS's registered endpoint." Every other callback endpoint (/on_discover, /on_select, etc.) was correctly updated in this PR to use CallbackAuthorizationHeader. /catalog/push was missed.

Current (line 1564):

- $ref: '#/components/parameters/AuthorizationHeader'

Should be:

- $ref: '#/components/parameters/CallbackAuthorizationHeader'

---

Y-2 — HTTP 409 mapped to NackBadRequest in POST /catalog/subscription (line 1689)

The description at line 1619 reads: "A 409 NackBadRequest is returned when an identical networkIds+schemaTypes combination is already active." This is self-contradictory — HTTP 409 signals Conflict; NackBadRequest is defined for HTTP 400. Everywhere else in the spec, 409 maps to AckNoCallback (see /catalog/push line 1593 for comparison).

Current (lines 1688–1689):

'409':
  $ref: '#/components/responses/NackBadRequest'

Fix options:

• (a) Downgrade to '400': $ref: '#/components/responses/NackBadRequest' if the intent is "client error", or
• (b) Introduce a NackConflict response component and wire it at 409.

---

docs/API.md (NFH-006)

A6-1 — Catalog infrastructure endpoint list is stale and wrong (lines 143–154)

The listed paths do not match beckn.yaml:

Listed in API.md	Reality in beckn.yaml
GET /catalog/subscriptions	Doesn't exist — correct path is GET /catalog/subscription (same path as POST/DELETE, no trailing s)
GET|DELETE /catalog/subscription/{subscriptionId}	Doesn't exist — DELETE operates on /catalog/subscription with a query param, not a path param
GET /catalog/pull/result/{requestId}/{filename}	Doesn't exist — async results are delivered via POST /catalog/on_pull callback

Paths entirely missing from the listing: POST /catalog/push, POST /catalog/on_pull, POST /catalog/search.

---

A6-2 — "Master resource search" section lists three endpoints that don't exist in beckn.yaml (lines 149–153)

POST /catalog/master/search
GET  /catalog/master/schemaTypes
GET  /catalog/master/{masterItemId}

None of these paths are defined in api/v2.0.0/beckn.yaml. This section should either be removed or explicitly marked as planned/future until the paths are added to the canonical contract.

---

A6-3 — Feedback links use stale RFC-006 label instead of NFH-006 (line 18)

All three feedback links (Issues, Discussions, Pull Requests) filter by label%3A%22RFC-006%22. Should be NFH-006.

---

A6-4 — References section links to old filename (line 188)

./00_Keyword_Definitions.md does not exist. Should be ./Keyword_Definitions.md.

---

docs/Keyword_Definitions.md (NFH-002)

K-1 — Status field contradicts body text

The header says **Status:** PUBLISHED. The Implementation report, Stress test report, and Conformance impact fields all say "This document is at Initial Draft status." The status header should be Draft.

---

K-2 — All three feedback links are broken (line 17)

• Issues URL: label%3A%NFH-002%22 — missing the opening %22, produces a malformed URL. Should be label%3A%22NFH-002%22.
• Discussions link: uses RFC-003 label — should be NFH-002.
• Pull Requests link: uses RFC-003 label — should be NFH-002.

---

K-3 — Examples section uses v1 terminology (lines 137–143)

The conformance examples reference search, on_search, and context.bpp_uri. In Beckn v2 the action is discover/on_discover and the field is context.bppUri. Using v1 names in the document that defines normative keywords for v2 sends the wrong signal to implementers reading it as a reference.

---

K-4 — References section links to old filename (line 157)

./00_Keyword_Definitions.md does not exist. Should be ./Keyword_Definitions.md.

---

docs/RFC_Authoring_Guide.md (NFH-010)

G-1 — Latest editor's draft URL points to old filename (line 21)

Currently points to NFH-006_RFC_Writing_Guide.md. The actual file on the draft branch is RFC_Authoring_Guide.md. Should be:

https://github.com/beckn/protocol-specifications-v2/blob/draft/docs/RFC_Authoring_Guide.md

---

G-2 — All three feedback links use stale RFC-006 label instead of NFH-010 (lines 34–43)

The document's own ID is NFH-010. The feedback links still filter by RFC-006 — the ID it carried before renaming.

---

G-3 — Multiple cross-references to ./Design_Guide.md (NFH-009) which doesn't exist in docs/ (lines 26, 175, 189, 558, 826, 834, 842)

Design_Guide.md is not present in the repository. Authentication_and_Trust.md and Communication_Protocol.md already handle this correctly — they link to the draft-branch URL with the annotation (drafted on 'draft' branch, undergoing review). The same pattern should be applied here.

---

docs/RFC_Template.md (NFH-011)

T-1 — References section links to old filename (line 134)

./00_Keyword_Definitions.md does not exist. Should be ./Keyword_Definitions.md.

---

Systemic — 5 REQUIRED-standard docs linked but absent from docs/

RFC_Publication_Summary.md lists the following as Protocol Standard — REQUIRED, but none of the files exist in docs/:

NFH ID	Missing file	Also linked from
NFH-003	The_Beckn_Protocol_Stack.md	Introduction.md
NFH-004	Core_Data_Schema.md	Schema_Design_Guide.md
NFH-005	Linked_Data_Schema.md	Introduction.md, Schema_Design_Guide.md
NFH-008	Error_Codes.md	—
NFH-009	Design_Guide.md	RFC_Authoring_Guide.md, Schema_Design_Guide.md

Authentication_and_Trust.md and Communication_Protocol.md already set the right precedent — they replace bare local links with draft-branch URLs and annotate them (drafted on 'draft' branch, undergoing review). The affected docs (Introduction.md, Schema_Design_Guide.md, RFC_Authoring_Guide.md) should do the same.

---

Summary

#	File	Issue	Severity
Y-1	beckn.yaml	/catalog/push wrong auth header parameter	Medium
Y-2	beckn.yaml	409 response mapped to NackBadRequest	Medium
A6-1	API.md	Catalog endpoint list has wrong/missing paths	High
A6-2	API.md	Master resource search lists 3 non-existent endpoints	High
A6-3	API.md	Feedback labels use stale RFC-006	Low
A6-4	API.md	Stale 00_Keyword_Definitions.md reference	Low
K-1	Keyword_Definitions.md	Status "PUBLISHED" contradicts "Initial Draft" body	Low
K-2	Keyword_Definitions.md	All 3 feedback links broken / wrong labels	Low
K-3	Keyword_Definitions.md	Examples use v1 search/on_search/bpp_uri	Medium
K-4	Keyword_Definitions.md	Stale 00_Keyword_Definitions.md reference	Low
G-1	RFC_Authoring_Guide.md	Editor's draft URL points to old filename	Low
G-2	RFC_Authoring_Guide.md	Feedback labels use stale RFC-006	Low
G-3	RFC_Authoring_Guide.md	Multiple links to non-existent Design_Guide.md	Medium
T-1	RFC_Template.md	Stale 00_Keyword_Definitions.md reference	Low
S-1	4 docs + summary index	Local links to 5 REQUIRED docs not present in docs/	Medium

[ravi-prakash-v]

Thanks for the deeper pass.

Y-1, Y-2 (beckn.yaml): addressed by Anand in #169, now merged. NackConflict at 409 on /catalog/subscription. /catalog/push kept on AuthorizationHeader with an Authentication note explaining why: CallbackAuthorizationHeader requires a request-signature from a triggering request, and /catalog/push is a CS-initiated push with no triggering DS request.

Everything else fixed in cdd6c60:

• A6-1: docs/API.md catalog listing rewritten to match beckn.yaml (drops /catalog/subscriptions and /catalog/subscription/{subscriptionId}, adds /catalog/push, /catalog/on_pull, /catalog/search).
• A6-2: master/search section marked as planned, not yet in the canonical contract.
• A6-3, G-2: stale RFC-006 label switched to NFH-006 (API.md) / NFH-010 (RFC_Authoring_Guide.md).
• A6-4, K-4, T-1: broken 00_Keyword_Definitions.md references retargeted to Keyword_Definitions.md.
• K-1: status corrected PUBLISHED -> Draft.
• K-2: broken NFH-002 URL escape fixed; RFC-003 labels in Discussions and PR URLs corrected to NFH-002.
• K-3: examples updated to v2 terms (search -> discover, on_search -> on_discover, context.bpp_uri -> context.bppUri).
• G-1: editor's draft URL retargeted to RFC_Authoring_Guide.md.
• G-3: all ./Design_Guide.md links in NFH-010 retargeted to the draft branch with a forthcoming-review annotation.
• S-1: Introduction.md, Schema_Design_Guide.md, RFC_Publication_Summary.md links to NFH-003/004/005/008/009 retargeted to the draft branch with annotation. RFC_Publication_Summary.md status corrected from "Protocol Standard, REQUIRED" to "Drafted on draft branch (under review)" for those rows.

Take another look when convenient.

[nirmay]

The beckn.yaml was updated to move AckNoCallback to 202, but Communication_Protocol.md and API.md were not. All 4 occurrences need 409 → 202:

Additionally, now that AckNoCallback is on 202, the NFH-013 response table should add a NackConflict row for 409 so the table reflects the full response surface

Everything else is clean. Once the above is fixed, the PR is good to merge.

@ravi-prakash-v @anandp504

[ravi-prakash-v]

Done in a7adf7c.

• docs/API.md: AckNoCallback listed at 202 in the standard response families.
• docs/Communication_Protocol.md (NFH-013):
  • Response families table: AckNoCallback row moved to 202.
  • CON-013-09 updated to (HTTP 202).
  • FAQ entry contrasting AckNoCallback and NackDiscretionary updated to 202.
  • Added a NackConflict row at 409 so the table reflects the full response surface from Add NackConflict for 409; clarify /catalog/push auth header #169.

[nirmay]

All the issues raised are now resolved.
Approved