DR SearchResponse.reg_records is typed 'object' but should be 'array'

[jeremi]

DR SearchResponse.reg_records is typed object but should be array

Repo: spdci/api-standards
File: dr_api_v1.0.0.yaml
Path in spec: components.schemas.SearchResponse...search_response.items.data.reg_records
Line (current spec): ~1223

Summary

In dr_api_v1.0.0.yaml, the reg_records field inside SearchResponse is declared as type: object. This is inconsistent with:

• social_api_v1.0.0.yaml, where the same field is type: array
• crvs_api_v1.0.0.yaml, where the same field is type: array
• The field's own description, which carries the JSON-LD annotation @container: "@set" (i.e. the value is a set of records)
• The neighbouring pagination.total_count, which is sized as the count of records inside reg_records, implying a collection

fr_api_v1.0.0.yaml has the same type: object defect, fixed downstream in the compliance suite (see related context below). DR was not patched at the same time.

Reproduction

The shape returned by a conforming DR server, mirroring SR/CRVS, is:

{
  "data": {
    "reg_record_type": "spdci-extensions-dci:DisabledPerson",
    "reg_records": [
      { "@type": "spdci:DisabledPerson", "personal_details": {...}, "disability_status": "Approved", ... }
    ]
  }
}

Validating this payload against the published DR spec with any standard OpenAPI validator (AJV, openapi-validator, etc.) fails because reg_records is declared type: object, not type: array.

Proposed fix

Change reg_records in DR's SearchResponse from:

reg_records:
  type: object
  description: |
    The "group" object contains fields expected in response of search
    @context: https://schema.spdci.org/extensions/dr/v1/DRPerson.jsonld <br>
    @type: "DisabledPerson" <br>
    @container: "@set" <br>
  example:
    type: object
    description: |
      ...
    example:
      personal_details: {...}
      disability_status: Approved
      ...

…to (mirroring FR's already-patched shape and SR/CRVS):

reg_records:
  type: array
  description: |
    The "group" object contains fields expected in response of search
    @context: https://schema.spdci.org/extensions/dr/v1/DRPerson.jsonld <br>
    @type: "DisabledPerson" <br>
    @container: "@set" <br>
  items:
    type: object
    description: |
      ...
    example:
      personal_details: {...}
      disability_status: Approved
      ...

The change is purely structural: the example payload and field descriptions are preserved; the misplaced example: { type: object, description: ..., example: {...} } wrapper is replaced with a proper items: schema.

Related

The downstream SPDCI compliance test suite tracks this and the FR equivalent in its SPEC_ISSUES_REPORT.md (item #3, "reg_records type inconsistency"). FR was already fixed upstream in a prior PR; DR was overlooked.

Impact

Any DR server returning a conforming reg_records array (i.e. the same shape SR and CRVS already use) fails OpenAPI validation, even though the payload is semantically correct per the JSON-LD annotation. This blocks tooling and compliance pipelines that validate responses against the spec.