---
id: TST-PFM-DJE-018
title: Keyed item decision
kind: unit
product_area: platform
module: data-job-engine
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: macroservice-libraries
files:
  - packages/data-jobs/src/keyed-item-decision.spec.ts
implements: []
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: In-memory fixtures and restored dependency doubles.
evidence:
  - 'macroservice-libraries:packages/data-jobs/src/keyed-item-decision.spec.ts'
assertion_inventory:
  - comparing a delivery with the revision the crosswalk last applied
  - 'orders two sequences as numbers, so 10 follows 9'
  - 'orders two instants as text, which is what ISO-8601 is for'
  - >-
    applies a delivery that carries no revision, because a producer that sends none has said nothing
    to order by
  - what a keyed item does
  - creates the record when the key is new
  - updates the record the crosswalk names when the delivery is newer
  - 'skips a delivery that has already been applied, which is what a rerun of the same file is'
  - 'skips a delivery a newer one has overtaken, so a late file never undoes a current record'
  - never lets an insert write a second record for a key that is already loaded
  - >-
    updates without a revision at all, because an upsert of unversioned records is the producer
    saying "this is current"
  - the conflict policy
  - >-
    compares the version this crosswalk last wrote under reject, so a change made since is a
    conflict
  - 'is reject when the job names no policy, which is the recommended default'
  - 'compares nothing under overwrite, which is the whole of what that permission buys'
  - >-
    honours the caller's own expectedVersion whatever the policy says, because it is a sharper
    question
  - 'updates the record a producer named itself, for a producer that knows the destination id'
  - what a keyed patch does (D-38)
  - 'skips a patch older than the revision applied, so a late file cannot put old values back'
  - >-
    writes a newer patch against the version this producer last wrote, so a newer manual edit is a
    conflict
  - 'applies a patch of the revision already applied, a further part of it, still against the version'
  - 'leaves a patch whose key no row answers to the domain, because a patch never creates'
registration_note: Registration describes existing source; the suite is not executed by this documentation job.
---

# Keyed item decision

## Verification Boundary

The suite checks an isolated production calculation, declaration or adapter. The structured assertion inventory records the checks present at the pinned revision.

## What This Suite Proves

The existing checks exercise keyed item decision. The specification bindings identify the narrower outcomes supported by those assertions.

## What It Does Not Prove

An isolated check does not establish a deployed workflow, database enforcement or complete feature acceptance.

## Real Dependencies and Test Doubles

The production function or declaration is exercised with in-memory inputs and dependency doubles. This boundary does not require a live database.

## Must Not Be Doubled

The production function under examination and its returned decisions remain real; replacing their answers defeats the check.