[snyaggarwal]

OpenConceptLab/ocl_issues#2943: the ticket's docs to-do.

Documents the API change in OpenConceptLab/oclapi2#981:

• collectionReferenceEvaluation.md, "How OCL picks a source version": system-version entries resolve in the collection owner's namespace (owner URL registry, then the owner's repositories, then the global registry), and only one version per source is allowed, as in FHIR's $expand. A collection whose own references name both versions stays valid.
• collectionReferenceEvaluation.md, Expansion Parameters table: one version per system.
• expansions.md, "Generate an expansion": the 400 response for two versions of one source.

Sibling PRs:

• OpenConceptLab/ocl_issues#2943 | Expansion system-version resolves in the owner namespace and rejects two versions of one source oclapi2#981 (API)

Merge after OpenConceptLab/oclapi2#981 is deployed.

🤖 Generated with Claude Code

[snyaggarwal]

Verdict: Approve with one non-blocking nit

The documentation matches the issue decision and the intended API behavior: owner-namespace resolution, one system-version per source, a 400 with no expansion for conflicts, and version-pinned references remaining valid. I left one P3 inline comment to keep the 201 response status/body together instead of splitting them with the new 400 example.

Merge sequencing: keep the stated dependency and merge/deploy this only after OpenConceptLab/oclapi2#981 is fixed and deployed.

Open-core boundary concerns: none.

(snyaggarwal • Codex review)

[snyaggarwal]

Verdict: Approve

Re-reviewed at 1b44fea. The prior P3 is fixed: the 201 status and response body are together, the 400 example follows them, and the page now also documents that a non-string system-version is rejected. The documentation matches the updated API PR and the issue decision.

Findings/nits: none. Open-core boundary concerns: none. Keep the stated sequencing and merge/deploy this only after OpenConceptLab/oclapi2#981 is deployed.

(snyaggarwal • Codex re-review)

[snyaggarwal]

Verdict: No findings; content is merge-ready, but hold the merge

Re-reviewed the unchanged docs against API head a9be5723. The owner-namespace wording already covers the added reference behavior, and the error examples remain accurate. No documentation findings or open-core boundary concerns.

Merge recommendation: do not merge/deploy this yet because it documents #981. Merge it only after the API P2 is fixed, #981 is green and merged, and the API change is deployed.

(snyaggarwal • Codex re-review)

[snyaggarwal]

Verdict: No findings or nits; content is merge-ready, but hold the merge

Re-reviewed the unchanged documentation against API head 9f924855. It still accurately describes owner-namespace resolution, one version per source, and the 400 behavior. No documentation, security, or open-core boundary findings.

Merge recommendation: hold this PR because it documents #981. Merge/deploy it only after the API P2 is fixed, #981 is green and merged, and the API change is deployed.

(snyaggarwal • Codex re-review)