Section pack_nutrition — INPUTS ONLY, keyed by production chapter. The per-100 g values, their units and the default serving come from the production chapter's nutrition table and are read-only here: they are written on the production chapter (FoodProductionChapterWrite.nutrition). Per-serving values are computed for a serving whose automaticCalculation is true, and entered by the caller for a serving whose automaticCalculation is false.

An entry addresses a production chapter linked to the specification (on a create: referenced by this same create). A productionChapterId that is not linked is a 422 naming the entry; the same productionChapterId twice is a 422 naming the second occurrence. Entries are not created or removed here: a linked chapter the array does not carry keeps what it holds.

Within an entry:

• servings: replaces the ADDITIONAL servings in full (the default serving is read-only); null or absent keeps them, [] removes them all. A servingId already on the table updates that serving; a servingId not on the table adds a serving with that id; a serving on the table the array does not carry is removed with its per-serving values. The default serving's id is a 422 naming the item; the same servingId twice is a 422 naming the second occurrence.
• nutrients: sets what it names; a nutrient it does not name keeps what it holds. A nutrientId absent from the production chapter's nutrition table is a 422 naming the item. displayToConsumer null or absent keeps the flag. perServing carries the manual values of a serving whose automaticCalculation is false (after the servings above are applied); a servingId of a serving whose automaticCalculation is true, or that is not on the table, is a 422 naming the item. Within a perServing item, null or absent keeps the value.
• nutritionalAnalysisFileIds: replaces the analysis files in full; null or absent keeps them, [] clears them. A file that does not exist or is not a nutritional-analysis file is a 422 naming the section.

Merged (assortment) mode is out of scope: on a specification in merged mode the section is refused with a 422 naming the section.

The manual claims the chapter carries, replaced in full.

REPLACE ALGORITHM — the section holds claims of both origins, so the replace is scoped to the manual ones:

• a manual claim absent from the array is removed;
• a manual claim present in the array is kept as it stands (its server-side detail is not reset);
• an id not yet on the chapter is added as a manual claim, in the list its claimType names;
• an AUTOMATIC claim is never touched — not removed, not converted, not counted as a duplicate of a manual one.

Sending the id of a claim that is currently AUTOMATIC does not adopt it: it stays automatic and no second entry appears.

The same id twice under the SAME claimType is collapsed silently; the same id under two different types is a contradiction, refused with a 422 naming the second occurrence's claimType.

null or absent means the section is NOT supplied and keeps what the chapter already holds (template defaults on a create) — it does NOT clear the manual claims. Send [] to clear them.

ERROR ATTRIBUTION. Refusals the payload alone can produce — a missing claimId or claimType, the duplicate contradiction above — name the exact entry (labellingChapter.claims[1].claimType). Everything about the claim ITSELF is checked by the platform when the link is written: the claim exists, is of the specification's product type, is the active version, and — for a library claim — belongs to the specification owner. Those refusals are 422s naming the SECTION (labellingChapter.claims), and the message identifies the offending id.

A marketing or nutritional claim id that exists but is not visible to your company answers 403: treat 403 on this section as "one of these claim ids is not yours".

Section pack_product_info — WRITE side. Values copied from the trade item (product name, GTIN, the trade item's own net content, variable weight, drained net weight) are NOT writable: they derive from tradeItemId server-side and appear on the read side; here only their on-pack flags are set. Extra net contents are written in full. Absent fields keep the template defaults.

Section nutriscore — INPUTS ONLY, keyed by production chapter. An entry addresses a production chapter linked to the specification (on a create: referenced by this same create, productionChapter.chapterId); a productionChapterId that is not linked is a 422 naming the entry. Entries are not created or removed here: a linked chapter not carried in the array keeps what it holds. null or absent = section not supplied.

Within an entry only productionChapterId is required. A field that is null or absent keeps what the entry holds (empty on a create): the platform's own validation flags an entry without a product type or a percentage as incomplete; it does not refuse it.

Merged (assortment) mode is out of scope: this write addresses the per-chapter entries. A chapter later put in merged mode keeps one merged entry under another key and is not writable here.

Section consumer_instruction — four blocks, each supplied independently (see the block semantics above).

Section sorting_instruction — target streams with country-specific components, plus the recycling logos.

displaySortingInstructions is not only a display flag: turning it OFF CLEARS the streams (the platform drops them when the section is not shown on pack). A payload carrying false together with a non-empty streams array is therefore a contradiction, refused with a 422 naming displaySortingInstructions - the streams would otherwise be accepted and then removed.

streams and the countries inside a stream are each replaced in full when supplied; absent or null keeps what the chapter holds (template defaults on a create). A stream is keyed by targetStreamId and a country row by countryId - the same key twice is a 422 naming the second occurrence.

Section gmo_risk_analysis — the inputs of the rows the platform generated from the recipe.

Each entry addresses one generated row by materialId AND ingredientId (see the note above: an absent ingredientId is part of the key, not an omitted field). A pair that matches no generated row is a 422 naming the entry, and the same pair twice is a 422 naming the second occurrence. A row the array does not carry keeps what it holds.

null or absent = section not supplied.

Section pack_marketing_info.

Section pack_business_name_and_address: the consumer-service contact and an additional text printed on pack, and whether the health marks and packer codes of the production sites are shown. The codes themselves come from the production chapters' sites and are read on BusinessNameAndAddressRead.

Custom field VALUES, one entry per custom component of the chapter. The template places retailer-defined custom components in the chapter; each component is a group of fields with its own published JSON Schema, listed by GET /v2/public/templates/{templateId}/chapters/ {chapterType}/custom-fields-schema. A published component never changes, and the same componentId is valid in every template that uses it.

WRITE RULES

• An entry replaces the values of its component: a field the values object does not carry is cleared. A component the array does not carry keeps what it holds. null or absent = not supplied.
• An entry is addressed by componentId. sectionCode is needed only when the component appears in more than one section of the chapter; without it, that is a 422 naming the missing field, customFields[i].sectionCode.
• A componentId (or componentId + sectionCode) that is not in the chapter, or the same one twice: 422 naming the entry.
• To change one field, read the entry, change it and send the whole values object back, with If-Match: the ETag of the chapter read. Without it, an edit made in between by the counterpart company is overwritten.
• values is validated against the component's JSON Schema (types, formats, bounds, reference-list items, files owned by your company). A refusal is a 422 naming the field, customFields[i].values.<field>.
• Mandatory fields (CustomFieldsSchema mandatoryFields) are not checked on write; they are checked when the section is validated.
• Who may write follows the section that holds the component: in a custom section either party may write; in a standard section the section's own rule applies (e.g. retailer or supplier sections of the general chapter: owner company only). A read returns one entry per custom component of the chapter, with sectionCode always set.