Equipment Data Practice: State Whether Bounds Are Included

An equipment data record can say that a value must lie between two bounds without stating whether the boundary values themselves are allowed. That ambiguity matters when a validation rule is written or an exported record is reviewed. This exercise makes the interval description explicit before it becomes software. It does not choose operating limits for equipment or replace the engineering documentation that defines a real limit.

Find the source and quantity behind the rule

Identify the field, quantity, unit and applicable equipment configuration. Ask where the proposed lower and upper limits came from and which version of the documentation supports them. A range copied from a chart, a user-interface hint and a contractual data requirement may have different purposes. Retain those roles rather than combining them into one unexplained interval.

Write the intended rule in words, including the treatment of each endpoint. If the source does not state whether equality is permitted, request clarification. A developer should not have to infer the engineering intention from the programming language's most convenient comparison operator.

Choose keywords that express the stated interval

The JSON Schema numeric reference distinguishes inclusive minimum and maximum from exclusiveMinimum and exclusiveMaximum. These keywords describe different boundary relationships. Record the applicable schema dialect and the actual rule, not merely the fact that a schema file contains two numbers.

The 2020-12 validation vocabulary document provides the corresponding keyword definitions. It is a specification document for that vocabulary; citing it does not establish the origin or appropriateness of an equipment limit. The schema expresses a rule whose engineering or business authority still needs to be named separately.

Review endpoint cases before general examples

Prepare an illustrative review sheet that identifies the lower boundary, upper boundary and intended equality treatment. Do not supply actual machine values unless the approved source does so. For each endpoint, ask what the documented rule would say about a value exactly equal to it. Then identify which nearby cases belong to the review and why.

Keep these proposed cases distinct from executed tests. A written expectation can reveal an ambiguous interval, but it is not a validation result. If the responsible developer later runs a validator, record the instance, schema identity, validator version and observed result. Preserve any difference between the expectation and implementation for explanation.

Keep units and representation decisions visible

A numeric keyword does not independently establish the unit of the equipment field. Confirm how the data model documents units and whether any conversion occurs before validation. A boundary expressed for one quantity should not be applied to a different representation merely because both are stored as numbers.

Also distinguish an absent value, a nonnumeric value and a numeric value outside the interval. They are different data questions that may involve different schema requirements. Do not silently convert an empty field into a boundary value to obtain a passing result. Retain the original representation and the stated handling rule.

If finite numerical representation affects a boundary case, document that as a separate implementation question. It should not cause an undocumented change from inclusive to exclusive limits. The agreed interval and the actual computational comparison both need explanations that another reviewer can assess.

Hand over the rule together with its authority

The final record should identify the quantity, unit, source version, equality treatment, schema dialect and unresolved cases. Link the schema rule back to its intended requirement. A recipient should be able to distinguish a policy change from a different encoding of the same policy.

When the source range changes, preserve the previous rule and the reason for revision. Recheck both endpoints and any related data requirements rather than changing one number in isolation. Do not infer that previously accepted records remain valid under the new rule, or that an old software result proves conformance to a revised engineering requirement.

Where several fields use numeric bounds, review each rule with its own quantity and authority rather than copying the first interval across the record. A temperature field, a count and a software timeout may all be numeric while expressing unrelated requirements. A shared schema editing workflow does not make those requirements interchangeable. Keep the proposed boundary cases field-specific and ask the owner to approve their meaning.

Another reviewer should be able to read the handover and explain what equality means at both ends without opening the implementation. If that remains unclear, revise the requirement note before calling the schema review complete. The implementation can then be examined against a stable statement of intention.

No equipment limits, validator outputs or physical test results were generated for this article. Its original diagrams explain interval decisions without invented numbers. More topics appear in the equipment specification record collection and article directory. An explicit statement about included bounds makes the data rule reviewable while keeping its authority attached to the appropriate source.