
A twelve-unit label sat on an eleven-unit grouping in two rows that exist to be copied. The label belongs to a twelve-unit line-up, three plus one in each of three zones; it had been written against the eleven-unit line-up, which is three plus one, three plus one and two plus one [TARGET]. The revision corrects both and records exactly where they sat: the owner-decision row for the cooling redundancy choice, and the coupling warning that tells procurement not to price one branch and adjust afterwards. No hydraulic number moved with the repair.
The Wrong Count Sat on Two Rows Meant to Be Copied
Neither location is a calculation. A reader who takes the owner-decision row at face value sees a choice offered between a label and two alternatives, with that label attached to the smallest of the three counts. A reader of the coupling warning sees an instruction about enquiry scope carrying the same wrong count. Both rows exist to be lifted into other documents, which is their function and the reason the error is worth a correction entry at all. The arithmetic sections were never wrong, and a reader who only worked the arithmetic would never have met the defect.
An enquiry issued from the uncorrected row would have named eleven units under a label whose line-up is twelve. The difference between the two is not one unit of margin. It is a zone that changes from two plus one to three plus one [MODELED].
Dual-Meaning Labels Were Already Graded Metadata Errors
The class was named before this instance surfaced. The controlled errata chapter grades a label carrying two meanings as a metadata-layer error and states in terms that it is more damaging than any single wrong number, because a cross-document roll-up will read a placeholder as signed evidence, or signed evidence as a placeholder, and will not raise an error while doing it. Its disposition for these labels is one line: they denote scheme branch numbers only and carry no confidence, maturity or recommendation. The correction in the hydraulic basis is that disposition applied, which is why its revision log lists the change as a label repair with no engineering number touched.
The errata chapter is itself a proposal. Replacement paragraphs have no force until the overall controller accepts a controlled change. Until that confirmation exists, the corrected revision and the original stand side by side, the original is explicitly not withdrawn, and a downstream reader can still open the version in which the label and the count disagree.
The register binds the label to the count
The object register holds the three branches as separate instance sets, and they count out against their labels: eleven, twelve and fifteen addressable cooling-distribution instances, each row carrying a branch state and a held model state [TARGET]. The register also does what the errata chapter asked and the earlier prose did not. Every row states its branch total in the same field as its quantity basis, so the label and the count cannot drift apart in a copy. That is a mechanism rather than a tidiness preference: a label that never appears without its count cannot be pasted into a decision row on its own. Procurement quantity is empty on every row. No instance is released.
That discipline was itself an errata item before it was a register field. The chapter that raised it observed that only the branch in current use had complete products behind it, so the other two existed as text while the first existed as quantities, zoning, redundancy argument, model instances and a bill of materials, and it required all five dimensions for every branch on the ground that a decision lands where the products are.
Limits and open items
Confirmed: unit count is a defining parameter of a cooling-distribution enquiry rather than a quantity adjusted afterwards; the three branches remain held, and held means available, maintained in parallel and awaiting adjudication, not selected, not issued for enquiry and not frozen for purchase. [FACT]
Register figures, not a buy list: eleven, twelve and fifteen addressable instances; a twelve-unit line-up of three plus one in each of three zones; an eleven-unit line-up of three plus one, three plus one and two plus one. [TARGET]
The one-unit difference is a zone that changes from two plus one to three plus one. [MODELED]
Open: written controller confirmation of the label disposition; an owner decision among the three held branches; all five product dimensions present for every branch. [HOLD]
Repairing a label leaves the choice of line-up exactly where it was. The correction makes the three branches comparable. It does not rank them, and the document says in its own words that it neither freezes a branch nor permits a downstream reader to freeze one on its authority.
Nothing here has been reviewed or sealed by an Engineer of Record. Nothing describes how any installed system behaved.
Which Surviving File May an Enquiry Copy From
One line from the party that owns the label namespace would overturn this, because the errata disposition is a candidate replacement text and not an accepted one. Until that line exists, the question for the owner's technical lead is which of the two surviving files an enquiry is allowed to copy from.
© 2026 K&K Data Service Inc. All rights reserved. Reproduction or republication is permitted only with clear attribution to K&K Data Service Inc. and a working hyperlink to the canonical URL of this article. Excerpts must preserve the technical context, maturity labels, assumptions, and limitations. No excerpt may imply project approval, field validation, certification, or endorsement that the original article does not state.
Source: K&K Data Service Inc., “A CDU Branch Label Said 11 Units; the Instance Count Was 12,” https://www.kkdatasvc.com/lab/errata-and-open-questions/a-branch-label-said-11-units-the-count-was-12/.
Discuss This Constraint. If your project record shows a different result, or the same failure domain under another name, we want to see it. Email inquiry@kkdatasvc.com or use the contact page.