Skip to content

BKG 2.0, EBL 3.0: SD-3102, SD-2930, SD-2931, SD-2860: Link to reference page for eblPlatform, sendToPlatform and IdentifyingCodes - #636

Merged
HenrikHL merged 21 commits into
masterfrom
SD-3102_Add-NA-to-Consignee-and-Endorsee
Jul 28, 2026
Merged

BKG 2.0, EBL 3.0: SD-3102, SD-2930, SD-2931, SD-2860: Link to reference page for eblPlatform, sendToPlatform and IdentifyingCodes#636
HenrikHL merged 21 commits into
masterfrom
SD-3102_Add-NA-to-Consignee-and-Endorsee

Conversation

@HenrikHL

@HenrikHL HenrikHL commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Change descriptions for eblPlatform and sendToPlatform: remove list of platforms and instead link to https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers
Change description for codeListProvider: remove list of code list providers and instead link to https://reference.dcsa.org/content/standards/dcsa-code-lists/party-code-list-providers

In some cases codeListProvider='NA' has been added in case no code list provider is available, when that is the case, the corresponding partyCodeMUST be set toNO VALUE`

In some cases codeListProvider='NONE has been added in case no code list provider is applicable, when that is the case, the corresponding partyCode MUST be set to NONE.

This PR fixes:

  • SD-3102: Update EBL (SI, TD), ISS, PINT to support On Behalf of Consignee [MSC request]
  • SD-2930: BKG 2.0.5 API: Add reference to the DCSA Code List Providers, sendToPlatform and eBLPlatform registries
  • SD-2931: EBL 3.0.4 API (TD, SI, ISSU, SUR, PINT, END): Add reference to the DCSA Code List Providers, sendToPlatform and eBLPlatform registries
  • SD-2860: Update BKG & EBL APIs: New eBL solution providers

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

EBL 3.0: Allow NA codeListProvider for Consignee/Endorsee identifying codes

✨ Enhancement 📝 Documentation 🕐 10-20 Minutes

Grey Divider

AI Description

• Add NA as an allowed codeListProvider when no identifying code exists.
• Introduce IdentifyingCodeExtended schema documenting NA/NO VALUE conditions.
• Update EBL, issuance, and PINT specs to reference the extended schema.
Diagram

graph TD
  A["EBL API spec"] --> D["IdentifyingCodeExtended"]
  B["Issuance API spec"] --> D
  C["PINT API spec"] --> D
  D --> E["codeListProvider=NA rule"] --> F["partyCode=NO VALUE rule"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Modify existing IdentifyingCode schema in-place
  • ➕ Single schema to maintain; avoids duplicating schema definitions
  • ➕ All uses automatically gain the NA option
  • ➖ Broad behavioral change across all party roles/contexts (higher compatibility risk)
  • ➖ Harder to scope the NA semantics only to Consignee/Endorsee as requested
2. Use oneOf to extend IdentifyingCode (e.g., IdentifyingCode | IdentifyingCodeWithNA)
  • ➕ Expresses extension without duplicating the full schema
  • ➕ Allows scoping the NA-capable variant to specific fields
  • ➖ More complex OpenAPI constructs for generators/validators
  • ➖ May reduce readability compared to a single explicit schema

Recommendation: Keep the current approach (introducing IdentifyingCodeExtended and updating only the relevant identifyingCodes arrays) because it scopes the NA allowance to the intended party roles while minimizing unintended downstream impacts. Consider oneOf only if schema duplication becomes a maintenance burden across versions.

Files changed (3) +201 / -6

Enhancement (3) +201 / -6
EBL_v3.0.4.yamlReference IdentifyingCodeExtended for selected party identifyingCodes +67/-2

Reference IdentifyingCodeExtended for selected party identifyingCodes

• Switches specific 'identifyingCodes.items' references from 'IdentifyingCode' to 'IdentifyingCodeExtended'. Adds the 'IdentifyingCodeExtended' schema including 'NA' as a documented option and the associated 'partyCode' condition.

ebl/v3/EBL_v3.0.4.yaml

EBL_ISS_v3.0.4.yamlAdd IdentifyingCodeExtended and update issuance party identifyingCodes to use it +67/-2

Add IdentifyingCodeExtended and update issuance party identifyingCodes to use it

• Introduces 'IdentifyingCodeExtended' to the issuance API components and updates the relevant party 'identifyingCodes' arrays to reference it. Documents 'NA' usage and the required 'NO VALUE' partyCode behavior when 'NA' is used.

ebl/v3/issuance/EBL_ISS_v3.0.4.yaml

EBL_PINT_v3.0.0.yamlAdd IdentifyingCodeExtended and update PINT party identifyingCodes to use it +67/-2

Add IdentifyingCodeExtended and update PINT party identifyingCodes to use it

• Adds the 'IdentifyingCodeExtended' schema to the PINT spec and updates the applicable party 'identifyingCodes.items' references to point to it. Captures the 'NA' provider option and the conditional requirement for 'partyCode'.

pint/v3/EBL_PINT_v3.0.0.yaml

@qodo-code-review

qodo-code-review Bot commented Jun 30, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

Grey Divider


Remediation recommended

1. Inconsistent NA condition ✓ Resolved 🐞 Bug ≡ Correctness
Description
IdentifyingCodeExtended’s description says to use NA when codeListProvider “does not exist”, but
codeListProvider is required by the same schema, making the normative rule internally
inconsistent. The same block also contains a typo (“Condtion”) in a MUST statement, replicated
across the three specs.
Code

ebl/v3/EBL_v3.0.4.yaml[R7709-7717]

+            **Condition:** When `codeListProvider` does not exist or is not applicable then `NA` MUST be used.
+          example: W3C
+        partyCode:
+          type: string
+          maxLength: 150
+          description: |
+            Code to identify the party as provided by the `codeListProvider`.
+
+            **Condtion:** when `codeListProvider='NA'` the corresponding `partyCode` MUST be set to `NO VALUE`.
Evidence
The schema requires codeListProvider, yet its own description discusses the case where
codeListProvider does not exist, which cannot occur under the schema as written; the same typo and
wording appear in issuance and PINT copies.

ebl/v3/EBL_v3.0.4.yaml[7668-7731]
ebl/v3/issuance/EBL_ISS_v3.0.4.yaml[741-794]
pint/v3/EBL_PINT_v3.0.0.yaml[1461-1496]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`IdentifyingCodeExtended` introduces normative wording that is internally inconsistent: it states that when `codeListProvider` does not exist then `NA` must be used, while the schema simultaneously requires `codeListProvider`. This should be reworded to describe the intended scenario (e.g., when no identifying code/provider is applicable, set `codeListProvider` to `NA`), and fix the typo `Condtion` -> `Condition`.

## Issue Context
The current text is likely meant to define how to populate the required `identifyingCodes` entry for Consignee/Endorsee when no real identifier is available.

## Fix Focus Areas
- ebl/v3/EBL_v3.0.4.yaml[7709-7718]
- ebl/v3/issuance/EBL_ISS_v3.0.4.yaml[772-781]
- pint/v3/EBL_PINT_v3.0.0.yaml[1474-1483]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Duplicate IdentifyingCode schemas ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
The PR introduces IdentifyingCodeExtended with the same structure as IdentifyingCode and
repoints Consignee/Endorsee to it, creating two parallel schema types for the same object shape.
This duplication increases drift risk (future edits must be applied twice) and needlessly fragments
schema/type usage across the specs.
Code

ebl/v3/EBL_v3.0.4.yaml[R6198-6201]

          type: array
          minItems: 1
          items:
-            $ref: '#/components/schemas/IdentifyingCode'
+            $ref: '#/components/schemas/IdentifyingCodeExtended'
Evidence
Consignee/Endorsee now reference IdentifyingCodeExtended, while both IdentifyingCode and
IdentifyingCodeExtended are defined in the same file with the same structural fields and required
list, demonstrating duplication and type fragmentation.

ebl/v3/EBL_v3.0.4.yaml[6197-6202]
ebl/v3/EBL_v3.0.4.yaml[6566-6571]
ebl/v3/EBL_v3.0.4.yaml[7609-7731]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`IdentifyingCodeExtended` duplicates `IdentifyingCode` (same properties + required list) and is only used to change descriptive/normative text about `NA`. This creates a maintenance hazard and inconsistent type usage.

## Issue Context
`Consignee.identifyingCodes` and `Endorsee.identifyingCodes` were switched to `$ref: IdentifyingCodeExtended`, while many other places still use `IdentifyingCode`. If the intent is simply to allow/document `NA`, prefer updating the existing `IdentifyingCode` schema (and keep refs unchanged), or otherwise factor the shared structure to prevent divergence.

## Fix Focus Areas
- ebl/v3/EBL_v3.0.4.yaml[6197-6202]
- ebl/v3/EBL_v3.0.4.yaml[6566-6571]
- ebl/v3/EBL_v3.0.4.yaml[7609-7731]
- ebl/v3/issuance/EBL_ISS_v3.0.4.yaml[3564-3570]
- pint/v3/EBL_PINT_v3.0.0.yaml[4258-4263]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

To customize comments, go to the Qodo configuration screen, or learn more in the docs.

Qodo Logo

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the EBL 3.0 OpenAPI specifications to allow a “Not Applicable” identifying-code provider (NA) for parties that must still provide an identifyingCodes entry even when no real identifying code exists (per SD-3102).

Changes:

  • Added a new IdentifyingCodeExtended schema (including NA in the documented provider list + NA-specific conditions).
  • Updated Consignee.identifyingCodes and Endorsee.identifyingCodes item schema references to IdentifyingCodeExtended.
  • Applied the above updates consistently across the PINT, Issuance, and main EBL v3 specs.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 6 comments.

File Description
pint/v3/EBL_PINT_v3.0.0.yaml Adds IdentifyingCodeExtended and switches Consignee/Endorsee identifyingCodes to it.
ebl/v3/issuance/EBL_ISS_v3.0.4.yaml Adds IdentifyingCodeExtended and switches Consignee/Endorsee identifyingCodes to it.
ebl/v3/EBL_v3.0.4.yaml Adds IdentifyingCodeExtended and switches Consignee/Endorsee identifyingCodes to it.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread pint/v3/EBL_PINT_v3.0.0.yaml Outdated
Comment thread pint/v3/EBL_PINT_v3.0.0.yaml Outdated
Comment thread ebl/v3/issuance/EBL_ISS_v3.0.4.yaml Outdated
Comment thread ebl/v3/issuance/EBL_ISS_v3.0.4.yaml Outdated
Comment thread ebl/v3/EBL_v3.0.4.yaml Outdated
Comment thread ebl/v3/EBL_v3.0.4.yaml Outdated

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 9 comments.

Comment thread pint/v3/EBL_PINT_v3.0.0.yaml
Comment thread pint/v3/EBL_PINT_v3.0.0.yaml
Comment thread ebl/v3/issuance/EBL_ISS_v3.0.4.yaml
Comment thread ebl/v3/issuance/EBL_ISS_v3.0.4.yaml
Comment thread ebl/v3/EBL_v3.0.4.yaml
Comment thread ebl/v3/EBL_v3.0.4.yaml
Comment thread pint/v3/EBL_PINT_v3.0.0.yaml Outdated
Comment thread ebl/v3/issuance/EBL_ISS_v3.0.4.yaml Outdated
Comment thread ebl/v3/EBL_v3.0.4.yaml Outdated
HenrikHL and others added 4 commits June 30, 2026 19:54
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.

Comment thread pint/v3/EBL_PINT_v3.0.0.yaml Outdated
Comment thread ebl/v3/issuance/EBL_ISS_v3.0.4.yaml Outdated

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

Comment thread ebl/v3/EBL_v3.0.4.yaml Outdated
Comment on lines 7648 to 7651
- `NA` (Not Applicable)

**Condition:** When an identifying code is not available then `codeListProvider` MUST be `NA`.
example: W3C

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

ebl/v3/surrender/EBL_SUR_v3.0.4.yaml:511

  • The IdentifyingCode.partyCode description doesn’t document how partyCode should be populated for the No Party placeholder, even though the schema now explicitly allows codeListProvider='NONE' and the earlier example sets partyCode to NONE. Adding the corresponding condition here would make the placeholder requirements self-contained and consistent.
        partyCode:
          type: string
          description: |
            Code to identify the party as provided by the `codeListProvider`
          maxLength: 150

Comment on lines 626 to 630
description: |
A code and value that uniquely identifies a party.
Code-based identifier for a party. Includes the provider, code, and list name.
properties:
codeListProvider:
type: string
Comment thread ebl/v3/surrender/EBL_SUR_v3.0.4.yaml Outdated
- `NONE` (To be used as part of the '**No Party**' object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`)
The eBL platform of the `Recipient Party`. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers).

**Condition:** When this ebl platform represents the **No Party** object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED` - the value MUST be `NONE`. The value `NONE` MUST be added to the allowed values from the link above.
Comment thread ebl/v3/EBL_v3.0.4.yaml
- `DOCU` (DocuTrade)
- `AEOT` (AEOTrade)
- `SGTD` (SGTraDex)
The eBL platform of the party. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers).
@HenrikHL HenrikHL changed the title EBL 3.0: SD-3102: Add NA to codeListProvider for Consignee and Endorsee BKG 2.0, EBL 3.0: SD-3102, SD-2930, SD-2931, SD-2860: Link to reference page for eblPlatform, sendToPlatform and IdentifyingCodes Jul 28, 2026
@HenrikHL
HenrikHL requested a review from Copilot July 28, 2026 07:24

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

ebl/v3/surrender/EBL_SUR_v3.0.4.yaml:498

  • In this condition, codeListProvider='NONE' should be formatted as code (backticks) for consistency with other conditions (e.g., codeListProvider='NA') and to avoid it being read as prose.
            **Condition:** When an identifying code is used in the **No Party** object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`, the special value codeListProvider='NONE' should be used instead of any value from the DCSA list of party code list providers.

ebl/v3/surrender/EBL_SUR_v3.0.4.yaml:273

  • The No Party example JSON is mis-indented: partyName is indented further than the surrounding fields, which makes the example harder to read and inconsistent with earlier versions (e.g., v3.0.3).
              'partyName': 'NONE',

ebl/v3/surrender/EBL_SUR_v3.0.4.yaml:290

  • RecipientParty.eblPlatform description refers to codeListProvider='NONE', but this field is eblPlatform. The special-case value should be documented as eblPlatform='NONE' for the No Party object; otherwise the description contradicts the example and the previous explicit NONE value.

This issue also appears on line 498 of the same file.

            The eBL platform of the `Recipient Party`. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers).

            **Condition:** When this ebl platform is used in the **No Party** object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`, the special value codeListProvider='NONE' should be used instead of any value from the DCSA list of party code list providers.

@HenrikHL

Copy link
Copy Markdown
Contributor Author

/agentic_review

@qodo-code-review

qodo-code-review Bot commented Jul 28, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

Grey Divider


Remediation recommended

1. No Party rule inconsistent ✓ Resolved 🐞 Bug ≡ Correctness
Description
In EBL Surrender v3.0.4, the schema note says a **No Party** object MUST use eblPlatform='NONE'
and identifying code values NONE, but the new per-field condition text says these special values
“should be used”, contradicting the MUST requirement in the same document. This creates unclear
conformance requirements for eblPlatform and codeListProvider in the No Party case.
Code

ebl/v3/surrender/EBL_SUR_v3.0.4.yaml[R288-290]

+            The eBL platform of the `Recipient Party`. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers).
+
+            **Condition:** When this eBL platform is used in the **No Party** object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`, the special value `eblPlatform='NONE'` should be used instead of any value from the DCSA list of eBL Solution Providers.
Evidence
The Surrender spec explicitly states the No Party object MUST be populated with NONE values, but
the updated field-level conditions introduced by this PR use “should” for eblPlatform and
codeListProvider, creating contradictory requirements.

ebl/v3/surrender/EBL_SUR_v3.0.4.yaml[269-281]
ebl/v3/surrender/EBL_SUR_v3.0.4.yaml[283-291]
ebl/v3/surrender/EBL_SUR_v3.0.4.yaml[492-506]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The **No Party** placeholder is defined as mandatory (MUST) in the `RecipientParty` schema note, but the newly added per-field condition text weakens that to “should be used” for `eblPlatform='NONE'` and `codeListProvider='NONE'`. This is internally contradictory and can lead to inconsistent producer/consumer behavior.

## Issue Context
The same No Party placeholder is described with strict values (`NONE`) and should be treated consistently as a normative requirement.

## Fix Focus Areas
- ebl/v3/surrender/EBL_SUR_v3.0.4.yaml[283-291]
- ebl/v3/surrender/EBL_SUR_v3.0.4.yaml[492-506]

## Suggested fix
Change the per-field condition wording from “should be used” to “**MUST** be used” for:
- `eblPlatform='NONE'` (No Party)
- `codeListProvider='NONE'` (No Party)
Keep `partyCode` as MUST (already is), so all three fields align with the No Party MUST note.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Platform constraint weakened 🐞 Bug ≡ Correctness
Description
Multiple eblPlatform/sendToPlatform fields now say “Possible values are …” instead of preserving
the explicit “value MUST be one of …” requirement, making the normative restriction ambiguous
(especially since these fields are not constrained by enum). This risks divergent interpretations
across versions and implementations about whether non-registry codes are allowed.
Code

ebl/v3/EBL_v3.0.4.yaml[5766]

+            The eBL platform of the party. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers).
Evidence
The changed v3.0.4 specs use non-normative “Possible values …” phrasing, while prior versions in the
repo used an explicit MUST requirement for the same field, demonstrating a regression in normative
clarity introduced by this PR.

ebl/v3/EBL_v3.0.4.yaml[5761-5767]
ebl/v3/EBL_v3.0.3.yaml[5761-5768]
ebl/v3/issuance/EBL_ISS_v3.0.4.yaml[624-630]
ebl/v3/issuance/EBL_ISS_v3.0.3.yaml[568-575]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Several schemas changed from an explicit normative constraint ("The value **MUST** be one of") to a looser phrasing ("Possible values are those in …"). Because these constraints are expressed only in prose (no `enum`), the new wording makes it unclear whether values outside the referenced registry are allowed.

## Issue Context
Earlier contract versions in this repo still use the explicit MUST language for these same fields, so the change introduces cross-version inconsistency and reduces conformance clarity.

## Fix Focus Areas
- ebl/v3/EBL_v3.0.4.yaml[5761-5767]
- ebl/v3/issuance/EBL_ISS_v3.0.4.yaml[624-630]
- bkg/v2/BKG_v2.0.5.yaml[4580-4586]
- pint/v3/EBL_PINT_v3.0.0.yaml[852-858]

## Suggested fix
Update the descriptions to retain normative language, e.g.:
- "The value **MUST** be one of the codes defined in the latest version 1.* of the DCSA … registry …"
Do the same for `sendToPlatform` and other touched occurrences in this PR to keep wording consistent across specs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

To customize comments, go to the Qodo configuration screen, or learn more in the docs.

Qodo Logo

Comment thread ebl/v3/EBL_v3.0.4.yaml
- `DOCU` (DocuTrade)
- `AEOT` (AEOTrade)
- `SGTD` (SGTraDex)
The eBL platform of the party. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Platform constraint weakened 🐞 Bug ≡ Correctness

Multiple eblPlatform/sendToPlatform fields now say “Possible values are …” instead of preserving
the explicit “value MUST be one of …” requirement, making the normative restriction ambiguous
(especially since these fields are not constrained by enum). This risks divergent interpretations
across versions and implementations about whether non-registry codes are allowed.
Agent Prompt
## Issue description
Several schemas changed from an explicit normative constraint ("The value **MUST** be one of") to a looser phrasing ("Possible values are those in …"). Because these constraints are expressed only in prose (no `enum`), the new wording makes it unclear whether values outside the referenced registry are allowed.

## Issue Context
Earlier contract versions in this repo still use the explicit MUST language for these same fields, so the change introduces cross-version inconsistency and reduces conformance clarity.

## Fix Focus Areas
- ebl/v3/EBL_v3.0.4.yaml[5761-5767]
- ebl/v3/issuance/EBL_ISS_v3.0.4.yaml[624-630]
- bkg/v2/BKG_v2.0.5.yaml[4580-4586]
- pint/v3/EBL_PINT_v3.0.0.yaml[852-858]

## Suggested fix
Update the descriptions to retain normative language, e.g.:
- "The value **MUST** be one of the codes defined in the latest version 1.* of the DCSA … registry …"
Do the same for `sendToPlatform` and other touched occurrences in this PR to keep wording consistent across specs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread ebl/v3/surrender/EBL_SUR_v3.0.4.yaml Outdated
@HenrikHL
HenrikHL merged commit 7bf37db into master Jul 28, 2026
1 check passed
@HenrikHL
HenrikHL deleted the SD-3102_Add-NA-to-Consignee-and-Endorsee branch July 28, 2026 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants