# RX-CLN-001 (B) – Candidate Provider / Payload Cleanup

## Decision

`candidate_provider_uri` identifies the service/system that supplied a candidate for the concrete reconciliation attempt.

`payload_json` contains only optional provider-specific supplementary information about the candidate that is not already represented by structured `CandidateItem` attributes or by `ReconciliationRun` discovery provenance.

## Persistence rule

The following values are not persisted redundantly in `payload_json`:

- Candidate identity/display: `uri`, `id`, `label`, `displayLabel`, `entityType`, `entityTypeUri`
- Candidate result fields: `score`, `rank`, `qualifier`, `candidateProviderUri`
- Run/discovery provenance: `discoveryMethod`, `adapterId`, `adapterKey`, `clientId`, `provider`, `store`, `targetVocabularyUri`, `scopeVocabularyUri`

Unknown provider-specific candidate metadata is preserved. Empty/null supplementary values are removed. If no supplementary metadata remains, `payload_json` is `NULL`.

## Current adapters

- xTree: `conceptId` and `status` may remain as supplementary candidate metadata; `qualifier` is persisted structurally.
- LocalStore: `role`, `lang`, `record_type` may remain; `provider`, `store`, `qualifier` are not duplicated in payload.
- Lobid/GND: provider-specific GND candidate metadata (for example type/broader data) may remain.
- Qdrant: the current standard response (`uri`, `label`, `entityType`, `score`) plus Rx-added `rank`, `clientId`, `discoveryMethod` leaves no payload and therefore persists `NULL`, unless the provider returns additional candidate metadata.

## Scope

No schema migration and no historical destructive data cleanup are included. Existing historical payloads remain untouched. The rule applies to newly persisted reconciliation results. Stable Reconcilix-owned provider URIs are a separate future decision.