An Equipment-Code Intelligence Layer

Container systems often agree on the physical unit and disagree on how to describe it. A booking platform may expect an ISO size-and-type code. A carrier feed may add a commercial equipment label. A depot file may store operating status in free text. An EDI message may use a directory code whose meaning depends on the selected release. The integration still has to decide whether those values are equivalent, related or in conflict.

HNOR is a useful test case because it carries several ideas in four letters: high-cube geometry, reefer equipment and a non-operating state. A careless integration can map that label to a generic reefer and lose the status, map it to a dry high cube and lose the equipment history, or assume a size that the source never supplied. An equipment-code intelligence layer would preserve each dimension of meaning and show the uncertainty to the receiving system.

The buyer and the first product

The buyer could be a transportation-management vendor, carrier integration team, NVOCC, freight forwarder, depot platform or equipment marketplace. These teams already maintain mapping tables. The pain appears when a partner changes a value, documentation lags, one code is overloaded or the same term reaches several downstream systems with different assumptions.

The first offer could be a hosted dictionary and validation API backed by versioned source records. It would accept a raw partner value plus context, return a structured interpretation and explain which parts are exact, inferred, ambiguous or unsupported. A browser interface would let operations and integration teams inspect the reasoning, compare sources and approve local overrides without editing production tables by hand.

Start with a richer canonical record

The product needs more than one catch-all equipment code. Its canonical record can separate fields that standards and partners already treat differently:

• Raw value exactly as received.
• Source organization, system, message and version.
• Container identification when available.
• Length, height and width class.
• Equipment family and physical type.
• Refrigeration or heating equipment characteristics.
• Current operating state.
• Full or empty indicator where supplied.
• Ownership, custody and location references.
• Intended use or service restrictions if the source defines them.
• Mapping confidence, unresolved questions and effective dates.

That structure follows the basic lesson in BIC's ISO size-and-type guide: length, height and equipment characteristics occupy distinct positions in the ISO sequence. BIC's current type-designation table also distinguishes general-purpose containers from several thermal-container categories. An operational label should not overwrite those physical attributes.

Preserve the difference between standards and partner vocabularies

Standards do not remove the need for context. UN/EDIFACT data element 8155 is an equipment-size-and-type description code list and notes that ISO 6346 codes may be used for seagoing containers. The same UNECE code list includes separate entries for nonworking reefers at specified lengths. Those entries describe equipment that is not actively controlling product temperature.

An Infor Nexus shipping-instruction integration guide also uses HNOR as High Cube Non Operating Reefer in its mapping material. That is good evidence that the label appears in real integration work. It is not evidence that HNOR is a universal ISO code or that every partner attaches identical size semantics.

The intelligence layer should store both facts. It can say, “This source documents HNOR with this expansion and these related values,” while leaving another source untouched until its own documentation is inspected. A global mapping created by copying one partner's table would be a product defect.

Four mapping outcomes are better than one answer

Every translation can end in one of four states:

1. Exact: The source and target define the same attributes at the required version.
2. Contextual: The mapping is valid only when another field, message type, partner or date is present.
3. Ambiguous: More than one target remains plausible because the input lacks size, status or another deciding attribute.
4. Unsupported: The current evidence does not justify a mapping.

Those outcomes give an integration a safe response. Exact values can flow automatically. Contextual values can require a predicate. Ambiguous records can enter a review queue. Unsupported values can be rejected with a precise request for the missing source or field.

An illustrative HNOR interpretation

Suppose a partner sends HNOR in an equipment-category field and provides a separate container number, but no size-and-type code. The partner's current guide defines HNOR as high-cube non-operating reefer. A responsible result might look like this in plain language:

• Raw value: HNOR.
• Source: named partner guide and version.
• Equipment family: reefer or thermal equipment, supported by the source.
• Operating state: non-operating, supported by the source.
• Height class: high cube, supported by the source label.
• Exact length: unresolved until a separate field, physical marking or documented partner variant supplies it.
• Current machinery condition: unresolved.
• Suitability for transport, storage or cargo: unresolved.
• Target mapping: withheld if the receiving code requires an exact length or machinery characteristic.

If the unit's physical record later supplies an ISO code, the service can add that value without deleting the original HNOR label. If the two records conflict, the result should display the conflict and ask for review. It should not silently prefer the code that happens to be easiest for the destination API.

This example is illustrative, not a universal mapping rule. The actual transformation must be tied to the inspected source documents and partner contract in force.

A source record that can survive change

Each dictionary entry should include publisher, title, URL or controlled document location, version, publication or effective date, access date, relevant field, supported interpretation, exclusions and reviewer. If a source is a PDF integration guide, retain the page or section reference. If it is a licensed standard, store the citation and internal review note without republishing protected tables.

Changes need a lifecycle. A new partner version can be drafted, compared, reviewed, approved and scheduled. Existing shipments or messages may still need the prior mapping. The API response should expose the mapping version so an audit can reproduce what happened later.

Local overrides deserve the same discipline. A customer may decide that one legacy code means a specific size in its private interface. The platform can support that rule while labeling it customer-specific, attaching an owner and expiration review, and preventing the override from leaking into the shared dictionary.

Validation before translation

Many bad mappings begin with bad input. The service can run inexpensive checks before attempting semantic translation:

• Does the raw value match the documented field format?
• Is the specified message version supported?
• Is a separate full-or-empty or operating-status field present?
• Does the container's visible size-and-type code agree with the supplied dimensions?
• Is the mapping effective for the event date?
• Does the target require an attribute the source does not provide?

Validation findings should use plain explanations. “Cannot determine length from HNOR alone under this source record” is more useful than “invalid equipment.” The first tells an operator what is missing and protects information that is already valid.

Distribution through the places mappings break

Early customers are likely to arrive through integration projects rather than general advertising. A focused launch could publish a small, well-sourced equipment dictionary, a sandbox API, sample transformation tests and connector notes for a few common message patterns. Each public entry would show its source and limits.

Partnerships with transportation-software implementers and depot platforms could put the service into projects that already face partner-code drift. A free comparison tool might let a user paste two documented code lists and see unmatched, changed or overloaded values. Paid use could add private dictionaries, approval workflows, webhooks and versioned production endpoints.

DCSA's standards work explains why common data models and aligned definitions matter across container-shipping systems. An HNOR code layer should align with recognized standards where they apply, while concentrating on the last-mile differences that standards adoption does not erase.

What the product must refuse to do

It must refuse to manufacture certainty. It should not claim universal interoperability, infer machinery performance from an equipment label, turn a commercial code into an inspection result or discard a raw source because a canonical field looks cleaner. It also should not reuse a mapping after its documented version or partner scope has expired.

Security and governance matter because a bad mapping can affect bookings, equipment availability and operational decisions. Changes need review, access controls and rollback. Customer-specific data should stay separated. Logs should show which input, context and mapping version produced an output without exposing unrelated commercial records.

The first test

Choose three real integrations that represent different layers, such as a carrier booking feed, a shipping-instruction message and a depot inventory export. Collect the official dictionaries and exact versions. Compare how each represents length, height, equipment type and operating status. Then list every pair that cannot be treated as equivalent without context.

That conflict list is the initial product backlog. HNOR.com gives the service a memorable example and a credible industry address. The quality of the business would come from what it preserves: source, version, raw value, operational distinction and an honest “unresolved” when the evidence stops.