--- id: ATS-PFM-DJE-015 scope: CAP-PFM-DJE-015 product_area: platform module: data-job-engine revision: 3 status: proposed approved_by: null approved_at: null source_sha: services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69 services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-PFM-DJE-015-01 title: Known keys return ordinary record representations level: api proves: - BR-CAP-PFM-DJE-015-01 preconditions: 'Import contacts, an organization, configuration items and custom-field definitions.' steps: - do: Request the loaded keys in a different order from the import. expect: Returned records match ordinary reads and follow the requested key order. provenance: test source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each key found with its record id, in the order the keys were asked expected: Returned records match ordinary reads and follow the requested key order. negative: false data_needs: Loaded record fixtures with owned details. bound_to: - TST-PFM-DJE-129 - TST-PFM-DJE-171 provenance: test source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each key found with its record id, in the order the keys were asked category: rule binding_evidence: - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each key found with its record id, in the order the keys were asked - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each record exactly as the ordinary read of one contact does - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#carries the owned collections the import wrote - >- services-platform:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each definition exactly as the ordinary read of one definition does, an archived one included - id: ATS-PFM-DJE-015-02 title: Unknown and unavailable records appear as missing level: api proves: - BR-CAP-PFM-DJE-015-02 preconditions: Prepare keys that were never loaded and mappings whose records are absent. steps: - do: 'Look up the prepared keys, including a repeated key.' expect: 'Unknown and absent records are listed as missing, with repeated keys represented once.' provenance: test source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#reports the key nothing loaded as missing expected: 'Unknown and absent records are listed as missing, with repeated keys represented once.' negative: true data_needs: Loaded and deliberately unresolved keys. bound_to: - TST-PFM-DJE-129 - TST-PFM-DJE-075 provenance: test source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#reports the key nothing loaded as missing category: edge binding_evidence: - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#reports the key nothing loaded as missing - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#reports a key whose record the tenant does not have as missing, never as a record - >- react-console:acceptance/crm/playwright/journeys/data-operations/CRM-ACC-0676.spec.ts#CRM-ACC-0676 - id: ATS-PFM-DJE-015-03 title: The lookup checks its request limit level: api proves: - BR-CAP-PFM-DJE-015-03 preconditions: Prepare a workspace with a known imported key. steps: - do: 'Request one hundred distinct keys, then one hundred and one.' expect: The first request succeeds and the second identifies the limit in its refusal. provenance: test source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers exactly 100 keys, the most a lookup may name expected: The first request succeeds and the second identifies the limit in its refusal. negative: true data_needs: A known key and generated unknown keys. bound_to: - TST-PFM-DJE-129 provenance: test source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers exactly 100 keys, the most a lookup may name category: boundary binding_evidence: - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers exactly 100 keys, the most a lookup may name - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#refuses more than 100 keys by InvalidRequest, naming the limit - id: ATS-PFM-DJE-015-04 title: Loading access still requires job-reading authority level: api proves: - BR-CAP-PFM-DJE-015-04 preconditions: 'Use a loading workspace, an authorized job reader and an ordinary record reader.' steps: - do: Request the same lookup with each account. expect: The job reader receives the record; the ordinary reader receives a permission refusal. provenance: test source: >- services-crm:modules/data-jobs/tests/e2e/records-by-source-key.e2e.spec.js#is served the lookup, answering the contact by its key and its id expected: The job reader receives the record; the ordinary reader receives a permission refusal. negative: true data_needs: The loading fixture and both account profiles. bound_to: - TST-PFM-DJE-111 provenance: test source: >- services-crm:modules/data-jobs/tests/e2e/records-by-source-key.e2e.spec.js#is served the lookup, answering the contact by its key and its id category: permission binding_evidence: - >- services-crm:modules/data-jobs/tests/e2e/records-by-source-key.e2e.spec.js#is served the lookup, answering the contact by its key and its id - >- services-crm:modules/data-jobs/tests/e2e/records-by-source-key.e2e.spec.js#refuses 403 permission_missing a caller who may read and update contacts but not read a job of contacts - id: ATS-PFM-DJE-015-05 title: Workspace and record-kind boundaries remain intact level: api proves: - BR-CAP-PFM-DJE-015-05 preconditions: Prepare a shared key spelling in two workspaces and different record kinds. steps: - do: Look up the key through each workspace and record-kind context. expect: >- Each workspace receives only its own match, and a contact key cannot resolve as an organization. provenance: test source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#looks a key up under its own object type only: a contact key is not an organization expected: >- Each workspace receives only its own match, and a contact key cannot resolve as an organization. negative: true data_needs: Two workspace fixtures with distinct mappings. bound_to: - TST-PFM-DJE-129 provenance: test source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#looks a key up under its own object type only: a contact key is not an organization category: invariant binding_evidence: - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#looks a key up under its own object type only: a contact key is not an organization - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers none of the first tenant’s keys in the other tenant - >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers the other tenant’s own record for a key both tenants hold, never the first tenant’s - id: ATS-PFM-DJE-015-06 title: Keyed reconciliation reads current saved records category: interaction level: api exercises: - CAP-PFM-DJE-012 - CAP-PFM-DJE-015 proves: - BR-CAP-PFM-DJE-012-03 - BR-CAP-PFM-DJE-015-01 - BR-CAP-PFM-DJE-015-06 preconditions: Import contacts with producer keys and edit one afterward. steps: - do: >- Request those keys in a different order from the file, including a repeated and an unknown key. expect: >- Lookup returns current records in requested key order once per key and names the unknown key as missing. provenance: proposed source: >- macroservice-libraries:packages/data-jobs/src/tests/integration/keyed-data-jobs.integration.spec.ts#writes no crosswalk row for an item it refused, so the corrected delivery of that key is a create; services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each record exactly as the ordinary read of one contact does; services-crm:modules/data-jobs/services/jobs/records-by-source-key.ts expected: >- Lookup returns current records in requested key order once per key and names the unknown key as missing. negative: true data_needs: Import contacts with producer keys and edit one afterward. bound_to: [] provenance: proposed source: >- macroservice-libraries:packages/data-jobs/src/tests/integration/keyed-data-jobs.integration.spec.ts#writes no crosswalk row for an item it refused, so the corrected delivery of that key is a create; services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each record exactly as the ordinary read of one contact does; services-crm:modules/data-jobs/services/jobs/records-by-source-key.ts - id: ATS-PFM-DJE-015-07 title: Completion with refusals remains visible in reconciliation category: interaction level: api exercises: - CAP-PFM-DJE-015 - CAP-PFM-DJE-016 proves: - BR-CAP-PFM-DJE-015-01 - BR-CAP-PFM-DJE-015-02 - BR-CAP-PFM-DJE-016-10 preconditions: Drive a package whose child completes with one refusal and otherwise saved records. steps: - do: >- Poll the run to settlement, inspect readiness, and look up the accepted and refused producer keys. expect: >- The run can finish succeeded while readiness names the refusal; accepted keys resolve and the refused creation is missing. provenance: proposed source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each record exactly as the ordinary read of one contact does; services-crm:modules/data-jobs/services/jobs/records-by-source-key.ts:readRecordsBySourceKey; services-platform:modules/data-jobs/services/jobs/records-by-source-key.ts:readCustomFieldsBySourceKey; services-platform:modules/data-jobs/tests/unit/run-summary.spec.ts#is not ready when a dataset’s counts do not add up to what the producer claimed expected: >- The run can finish succeeded while readiness names the refusal; accepted keys resolve and the refused creation is missing. negative: true data_needs: Drive a package whose child completes with one refusal and otherwise saved records. bound_to: [] provenance: proposed source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each record exactly as the ordinary read of one contact does; services-crm:modules/data-jobs/services/jobs/records-by-source-key.ts:readRecordsBySourceKey; services-platform:modules/data-jobs/services/jobs/records-by-source-key.ts:readCustomFieldsBySourceKey; services-platform:modules/data-jobs/tests/unit/run-summary.spec.ts#is not ready when a dataset’s counts do not add up to what the producer claimed - id: ATS-PFM-DJE-015-08 title: Reset removes loaded mappings before reconciliation and reload category: interaction level: api exercises: - CAP-PFM-DJE-015 - CAP-PFM-DJE-017 proves: - BR-CAP-PFM-DJE-015-02 - BR-CAP-PFM-DJE-015-05 - BR-CAP-PFM-DJE-017-02 - BR-CAP-PFM-DJE-017-04 preconditions: Load the same package in two isolated loading workspaces. steps: - do: >- Reset one, reconcile its keys, reload it, and compare both workspaces with their prior projections. expect: >- Reset keys become missing until reload; the other workspace remains unchanged and the reset fixture reproduces its records and numbers. provenance: proposed source: >- services-crm:modules/data-jobs/services/jobs/records-by-source-key.ts:readRecordsBySourceKey; services-platform:modules/data-jobs/services/jobs/records-by-source-key.ts:readCustomFieldsBySourceKey; services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#looks a key up under its own object type only: a contact key is not an organization; services-crm:modules/data-jobs/tests/integration/services/jobs/initial-import-guarantees.integration.spec.js#removes everything the load wrote: no contact, organization, imported type or crosswalk row is left; services-crm:modules/data-jobs/tests/integration/services/jobs/initial-import-guarantees.integration.spec.js#reloads the same records as the load before the reset, numbers included expected: >- Reset keys become missing until reload; the other workspace remains unchanged and the reset fixture reproduces its records and numbers. negative: true data_needs: Load the same package in two isolated loading workspaces. bound_to: [] provenance: proposed source: >- services-crm:modules/data-jobs/services/jobs/records-by-source-key.ts:readRecordsBySourceKey; services-platform:modules/data-jobs/services/jobs/records-by-source-key.ts:readCustomFieldsBySourceKey; services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#looks a key up under its own object type only: a contact key is not an organization; services-crm:modules/data-jobs/tests/integration/services/jobs/initial-import-guarantees.integration.spec.js#removes everything the load wrote: no contact, organization, imported type or crosswalk row is left; services-crm:modules/data-jobs/tests/integration/services/jobs/initial-import-guarantees.integration.spec.js#reloads the same records as the load before the reset, numbers included evidence: - >- services-crm: inspected producer-key route factories and schemas, lookup services, the ordinary-read comparison integration suite and the loading-workspace API suite. - >- services-platform: inspected the custom-field lookup service, its route and the definition reconciliation integration suite. - >- react-console: inspected the API reconciliation journey, including key trimming, missing records and access refusals. - >- Testing back-fill: related capability rules, domain invariants, state transitions and crossing workflows at the pinned source revisions. coverage: rule: covered transition: 'gap: FND-PFM-DJE-075' validation: 'gap: FND-PFM-DJE-075' permission: covered edge: covered failure: 'gap: FND-PFM-DJE-075' boundary: covered concurrency: 'gap: FND-PFM-DJE-075' invariant: covered interaction: covered coverage_notes: transition: >- Selected lifecycle examples do not cover every applicable object and batch transition. The linked finding retains the remaining matrix. execution: >- Covered means a specification scenario exists. Proposed scenarios and registered suites with no run result do not establish executed conformance. related: - CAP-PFM-DJE-012 - CAP-PFM-DJE-016 workflows: - WF-PFM-DJE-007 - WF-PFM-DJE-012 coverage_evidence: - rule: BR-CAP-PFM-DJE-015-01 scenarios: - ATS-PFM-DJE-015-01 - ATS-PFM-DJE-015-06 - ATS-PFM-DJE-015-07 provenance: proposed source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#answers each record exactly as the ordinary read of one contact does - rule: BR-CAP-PFM-DJE-015-02 scenarios: - ATS-PFM-DJE-015-02 - ATS-PFM-DJE-015-07 - ATS-PFM-DJE-015-08 provenance: proposed source: >- services-crm:modules/data-jobs/services/jobs/records-by-source-key.ts:readRecordsBySourceKey; services-platform:modules/data-jobs/services/jobs/records-by-source-key.ts:readCustomFieldsBySourceKey - rule: BR-CAP-PFM-DJE-015-03 scenarios: - ATS-PFM-DJE-015-03 provenance: proposed source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#refuses more than 100 keys by InvalidRequest, naming the limit - rule: BR-CAP-PFM-DJE-015-04 scenarios: - ATS-PFM-DJE-015-04 provenance: proposed source: 'services-crm:docs/data-jobs.md#Reading a load back by source key' - rule: BR-CAP-PFM-DJE-015-05 scenarios: - ATS-PFM-DJE-015-05 - ATS-PFM-DJE-015-08 provenance: proposed source: >- services-crm:modules/data-jobs/tests/integration/services/jobs/records-by-source-key.integration.spec.js#looks a key up under its own object type only: a contact key is not an organization --- # Reconcile loaded records using the producer’s keys: Capability Test Specification ## Coverage The structured coverage rows link required rules to their scenarios. A covered category has a defined check; executable coverage and successful execution require separate evidence. The category map keeps incomplete lifecycle matrices and other missing checks visible as findings. ## Interactions With Related Capabilities Keyed reconciliation reads current saved records. Completion with refusals remains visible in reconciliation. Reset removes loaded mappings before reconciliation and reload. The interaction scenarios use the related capabilities' rule references and identify the shared fixture and observable outcome.