A purchasing-data workbook can contain a tender item and an awarded item with the same short identifier. It is tempting to join them immediately and describe the award as fulfilling the requested item. That relationship needs evidence. In OCDS, an item’s identifier belongs to its array context; a matching value found elsewhere does not by itself establish a connection.

This guide uses the OCDS 1.1.5 identifier documentation read on 14 October 2026. We did not download a contracting dataset, execute a join or inspect an actual award. It provides a research-control method and makes no determination about contract performance or procurement compliance.

Retain the array as part of the reference

The official identifier guidance says item identifiers are unique within their array. The same value can occur in another array without implying a cross-reference. Its example distinguishes tender/items from awards/0/items. Read the field’s location as well as its value.

Define the relationship before choosing the key

Write down the question the comparison is meant to answer. Are you following updates to an item within the same award, or trying to connect a requested item to an awarded one? Those are different tasks. Preserve the contracting-process reference and the relevant parent object so that a later reviewer can identify exactly which item record was used.

For a hypothetical worksheet with two item columns, label one as the tender-side reference and the other as the award-side reference. Leave the relationship unresolved until a supported mapping is found. This is a design example, not a report that a buyer awarded a particular product or failed to supply a requested item.

Keep source paths in an exception log

An exception entry can record the process reference, release reference, array path, item value, source URL, access date and reason the relationship was investigated. Preserve the original descriptions alongside any shortened comparison labels. That gives another researcher a way to examine the same question without reconstructing the spreadsheet’s history.

If a parsing tool strips the parent award or array path, keep the raw record and repair the research copy before making a relationship claim. Do not fill the missing context with the nearest title or a similar description. Such similarities can identify candidates for review, but they are not proof of equivalence.

Separate an update from a cross-stage match

When comparing releases, first confirm that the records concern the same process and the same relevant array context. Then document the item relationship supported by those records. A later observation should retain its own release and date rather than overwrite the earlier source without a note.

When comparing tender and award stages, keep the evidence used for that cross-stage relationship explicitly attached to it. If the source does not provide enough information, report the gap. The absence of a reliable match does not prove that a buyer changed the specification improperly or that a supplier delivered the wrong product.

State the result at the right level

A defensible research finding describes the records connected and the evidence supporting that connection. It also names the unmatched records. A technical join that runs successfully is not an engineering acceptance, quantity inspection or legal interpretation of an award.

Needs editor verification: the actual records, publisher-specific mappings, current release history and any proposed item equivalence. None has been fabricated here. Our editorial recommendation is to keep array context visible and use a smaller supported relationship table when the evidence is incomplete. A count of joined rows should never substitute for an explanation of why those rows belong together.