Apply suggestions from code review

Co-authored-by: James McKinney <26463+jpmckinney@users.noreply.github.com>

docs/guidance/build/merging.md

@@ -14,7 +14,7 @@ The following examples show how updates and deletions are reflected in compiled
 
 The [tender updates and amendments example](../map/amendments.md) illustrates how releases are used to update field values and how updates are reflected in compiled and versioned releases.
 
-## Deletions
+## Deletion of fields and objects
 
 ### Fields
 

docs/guidance/map/amendments.md

@@ -8,7 +8,7 @@ Information about a contracting (or planning) process often changes over time.
 
 Each time information changes, a new OCDS release ought to be published. The new release can repeat information that was previously published, in addition to new and changed information.
 
-There are three types of change:
+There are three types of changes:
 
 * **New information**. For example, when information about the award of a contract is first released.
 * **Updates to existing information**. For example, to correct errors in earlier releases, or to make minor adjustments to titles, descriptions or dates.
@@ -18,7 +18,7 @@ The nature of a change can be made explicit using:
 
 * **The release tag** field (`tag`), which is used to identify the type of change. For example, 'contract' identifies information about a new contract, 'contractUpdate' identifies an update to existing information about a contract, and 'contractAmendment' identifies a formal amendment to a contract.
 
-* **The amendments** fields (`tender.amendments` and `contract.amendments`), which are used to list amendments along with their rationales and references to the releases that contain before and after values.
+* **The amendments** fields (`tender.amendments`, `awards.amendments` and `contracts.amendments`), which are used to list amendments along with their rationales and references to the releases that contain "before" and "after" values.
 
 ## Worked examples
 
@@ -38,9 +38,11 @@ A buyer publishes an opportunity for the purchase of office supplies.
 
 #### Tender update release
 
-The buyer now indicates the opportunity's main procurement category. The new information is not a formal amendment so the publisher uses the 'tenderUpdate' tag and omits the `tender.amendments` field.
+The buyer now indicates the opportunity's main procurement category. The new information is not a formal amendment, so the publisher uses the 'tenderUpdate' tag and omits the `tender.amendments` field.
 
+```{note}
 The publisher chooses to repeat fields whose values are unchanged from the previous release. Such fields can be omitted when a publication provides access to historic releases.
+```
 
 ```{jsoninclude} ../../examples/amendments/tender.json
 :jsonpointer: /records/0/releases/1
@@ -50,7 +52,7 @@ The publisher chooses to repeat fields whose values are unchanged from the previ
 
 #### Tender amendment release
 
-The buyer increases the estimated value of the opportunity. This change is a formal amendment so the publisher uses the 'tenderAmendment' tag and populates the `tender.amendments` field.
+The buyer increases the estimated value of the opportunity. This change is a formal amendment, so the publisher uses the 'tenderAmendment' tag and populates the `tender.amendments` field.
 
 Note that `tender.amendments` does not include the changed values. Rather, the `tender.value.amount` field itself is updated. 
 
@@ -64,7 +66,7 @@ Note that `tender.amendments` does not include the changed values. Rather, the `
 
 `releases` contains the above releases, `compiledRelease` contains the latest value of each field, and `versionedRelease` contains a history of changes to each field.
 
-The `releaseID` and `amendsReleaseID` fields in the `amendments` array of the compiled release can be looked up in `releases` and `versionedRelease` to identify what changed.
+The `releaseID` and `amendsReleaseID` fields in the `amendments` array of the compiled release can be looked up in `releases` and `versionedRelease` to determine what changed.
 
 ```{jsoninclude} ../../examples/amendments/tender.json
 :jsonpointer: /records/0
@@ -76,8 +78,8 @@ The `releaseID` and `amendsReleaseID` fields in the `amendments` array of the co
 [Download](../../examples/amendments/tender.json) the record example and use the [Data Review Tool](https://review.standard.open-contracting.org/) to explore the changes in the contracting process.
 ```
 
-```{admonition} Contract updates and amendments
-Contract updates and amendments are modelled in the same way: the 'contract', 'contractUpdate' and 'contractAmendment' release tags distinguish the type of change and amendments are listed in the `contract.amendments` field.
+```{admonition} Award and contract updates and amendments
+Award and contract updates and amendments are modelled in the same way. The 'award', 'contract', 'awardUpdate', 'contractUpdate' and 'contractAmendment' release tags indicate the type of change. Amendments are listed in the `awards.amendments` and `contracts.amendments` fields.
 ```
 
 ### Example 2: Amendments in a Easy Releases scenario

docs/guidance/map/buyers_suppliers.md

@@ -42,10 +42,7 @@ Siemens and Microsoft bid as a consortium for a contract.
 
 The contract is awarded to the consortium; however, the legal entity for the consortium is not created until after the contract award.
 
-Both Siemens and Microsoft are listed as suppliers on the contract award in OCDS, with `id`s constructed according to [`Organization.id`](../../schema/identifiers.md#organization-identifiers):
-
-```{field-description} ../../../build/current_lang/release-schema.json /definitions/Organization/properties/id
-```
+Both Siemens and Microsoft are listed as suppliers on the contract award:
 
 ```{jsoninclude} ../../examples/buyers_suppliers/consortia.json
 :jsonpointer: /releases

docs/primer/how.md

@@ -113,7 +113,7 @@ In addition to the default format of JSON, you can convert and publish your OCDS
 
 While the OCDS schema is described using JSON Schema, OCDS data can be converted from its JSON format to tabular formats such as CSV files or spreadsheets. JSON is favored by developers because it uses human-readable text to exchange complex information, such as nested objects. It can contain large volumes of information and is particularly good at handling one-to-many relationships (such as multiple bids per tender notice).
 
-Tabular formats, such as CSV (or comma separated values) are commonly used in spreadsheet applications and other analysis tools. Many people are comfortable working with spreadsheets using tools like Excel. While JSON is the default format, a good publication will publish tabular formats both so that more users’ needs can be satisfied.
+Tabular formats, such as CSV (or comma separated values) are commonly used in spreadsheet applications and other analysis tools. Many people are comfortable working with spreadsheets using tools like Excel. While JSON is the default format, a good publication will publish tabular formats as well, so that more users’ needs can be satisfied.
 
 The following examples show the same data in JSON and tabular format:
 

docs/schema/merging.md

@@ -43,14 +43,14 @@ To convert a field's value in a release to a **versioned value**, you must:
 
 A **versioned value** thus describes a field's value in a specific release.
 
-For example, a tender release sets the value of `tender.value.amount`.
+For example, a tender release sets the `tender.value.amount`field:
 
 ```{jsoninclude} ../examples/amendments/tender.json
 :jsonpointer: /records/0/releases/0
 :expand: tag, tender, value
 ```
 
-Following the steps above, the versioned value of `tender.value.amount` is:
+Following the steps above, the versioned value of the `tender.value.amount` field is:
 
 ```{jsoninclude} ../examples/amendments/tender.json
 :jsonpointer: /records/0/versionedRelease/tender/value/amount/0
@@ -59,14 +59,14 @@ Following the steps above, the versioned value of `tender.value.amount` is:
 
 In a **versioned release**, with a few exceptions, a field's value is replaced with an array of versioned values, which should be in chronological order by `releaseDate`.
 
-Following on from the example above, a later release updates the value of `tender.value.amount`.
+Following on from the example above, a later release updates the value of the `tender.value.amount` field:
 
 ```{jsoninclude} ../examples/amendments/tender.json
 :jsonpointer: /records/0/releases/2
 :expand: tag, tender, value
 ```
 
-In the versioned release, `tender.value.amount` is replaced with an array of versioned values:
+In the versioned release, the `tender.value.amount` field is an array, that now contains another versioned value:
 
 ```{jsoninclude} ../examples/amendments/tender.json
 :jsonpointer: /records/0/versionedRelease/tender/value