Classification depends on an object’s characteristics and its relevant connections to other objects. Making those dependencies explicit supports better analysis and reusable classification rulesets.
An export classification request may arrive as a part number, a software application, or a technical document.
The record looks self-contained. The analysis often is not.
A component may need to be understood in the context of the equipment it supports. Software may perform functions associated with a particular system. Manufacturing instructions may convey information about a material, component, or process whose characteristics are essential to the assessment.
The facts needed to classify one object can therefore reside in the records and determinations associated with another.
Export classification is relational. It depends on understanding what an object is and the connections relevant to its regulatory treatment.
In Stop Looking at the Classification Elephant Through the Transactional Keyhole, we explored why organizations should analyze classification populations rather than repeatedly research isolated requests. HEMSI dependencies develop that argument: relationships within those populations supply facts that can inform mass classification rules and rulesets.
What HEMSI Represents
HEMSI stands for Hardware, Equipment, Materials, Software, and Information.
At TC Engine, we use these categories as a common model for organizing the objects involved in export-control analysis. The model reflects a structure embedded in dual-use control lists, including the Wassenaar Arrangement’s list and national implementations of internationally agreed controls.
For example, the Commerce Control List organizes items within each category into five groups: equipment, assemblies and components; test, inspection and production equipment; materials; software; and technology. HEMSI provides an operational vocabulary aligned with that structure, using “Information” as the broader category within which applicable technology and technical-data determinations can be represented.
HEMSI does not replace the definitions or criteria of a particular regime. It helps organize the objects and relationships against which those criteria are evaluated.
A business may manage these objects in different systems. Hardware and equipment appear in product lifecycle management and enterprise resource planning applications. Material characteristics reside in specifications and supplier records. Software is maintained in repositories and release systems. Information is distributed across engineering applications, document repositories, and collaboration environments.
Classification work needs to connect the relevant facts across those boundaries.
A Classification Register Captures Only Part of the Picture
A classification register typically connects an identifier with a designation, supporting rationale, and approval.
Those records are valuable. Their usefulness increases when the organization can also establish which configuration was assessed, which other objects informed the determination, and which relationships remain relevant to its validity.
Consider a component record that identifies the part and its classification but does not connect it to the development or application evidence supporting the decision. A later reviewer may have to reconstruct that context.
The same problem arises when a document’s classification depends on its technical content and the item it concerns, but the relationship between those records exists only in an analyst’s notes.
A relational model makes that supporting context explicit and available for reuse.
Preserve Engineering Relationships and Information Associations
HEMSI dependencies can be established through different relationships.
A bill of material may provide a revision-controlled USED_IN relationship between a component and an assembly. The engineering application maintains that relationship as part of the product structure.
Information outside that managed structure may require an evidence-supported IS_FOR association to identify the item it concerns. A technical document, for example, may contain a part reference without having a formal relationship to that part in the engineering system.
These relationships have different origins and governance. The classification model should preserve that distinction.
Both can provide relevant context. The applicable criteria determine how that context affects the classification outcome.
Specially Designed (a)(2): A Relational Classification Question
The specially designed (a)(2) “catch” provides a direct example of why relationships matter.
Under the ITAR definition, paragraph (a)(2) addresses parts, components, accessories, attachments, or software for use in or with a defense article. The EAR definition similarly addresses those item types for use in or with commodities or defense articles enumerated or otherwise described on the CCL or USML. Both definitions also contain paragraph (b) releases that must be considered as applicable.
The analysis asks a relational question: What is this item for use in or with?
A maintained USED_IN record supplies direct engineering evidence for that question. It connects the component to an identified assembly or end item whose regulatory status can inform the analysis. Where the relationship passes through intermediate assemblies, the product structure can help trace the relevant connection.
The BOM relationship is an input to the determination. The applicable control entry, item facts, and release criteria complete the analysis.
For mass classification, this creates a practical opportunity: evaluate populations sharing relevant relationships and facts through approved rules, while preserving exceptions and unresolved cases.
Follow One Relational Population
Consider an illustrative engineering environment containing a system, its components, test equipment, associated software, material specifications, and maintenance instructions.
Each object introduces a different classification question.
| Object | Relevant context to examine |
|---|---|
| Hardware component | Its characteristics, development evidence, configuration, and documented relationships to assemblies or end items. |
| Test equipment | Its functions, capabilities, and the objects or activities it supports. |
| Material | Its composition, properties, specifications, and relevant application context. |
| Software | Its functionality, version, supported equipment, and development or operating purpose. |
| Information | What it conveys, which objects or activities it concerns, and the applicable information-control criteria. |
The relationships help locate the evidence needed for each assessment. They also reveal where a determination depends on an unresolved fact elsewhere in the population.
This creates a more useful starting point than five disconnected research queues.
A Dependency Does Not Automatically Transfer a Classification
Related objects do not necessarily share the same export classification.
A component’s presence in a controlled system does not, by itself, complete the component analysis. An association between a document and an item does not establish that every statement in the document is controlled information.
The dependency identifies context that must be evaluated. For information, that context contributes to an ECI identity that can inform subsequent release decisions; it does not itself authorize release.
A supported determination still requires the relevant facts, applicable regulatory criteria, and an explanation of how those facts satisfy—or fail to satisfy—the criteria.
The classification logic should make the role of each relationship explicit. Where the relationship is material to the outcome, its evidence, scope, and configuration must be sufficiently established.
A relational model makes the reasoning available for examination. It does not eliminate the need for that reasoning.
Sequence the Work Around Actual Dependencies
When one assessment requires facts from another object, the workflow should make that dependency visible.
A technical document assessment may require a supported classification and technical profile for the item it describes. Research into a component may require its development records or a verified configuration relationship.
Those dependencies help determine the order of work.
The sequence will vary with the population and applicable criteria. Evidence can move in either direction: a software specification may reveal a function needed to understand equipment, while a manufacturing document may supply characteristics missing from a material record.
The objective is to identify what must be resolved before a supported decision can be made.
Unresolved dependencies should remain visible through explicit review states rather than being concealed by a completed classification field.
Dependencies Inform Mass Classification Rulesets
Relationships help define which objects belong in a candidate population and which related facts an assessment needs. Components used in a particular configuration, software supporting a specified function, and information concerning an identified product each provide a different starting point.
A shared parent assembly can identify candidates for evaluation. Each member still needs the evidence required by the applicable criteria, including item-specific facts and relevant exclusions or releases.
The reusable asset is the supported relationship: its origin, configuration, scope, and connection to the determination. Preserving that context lets classification teams reuse evidence without turning proximity in a BOM into a blanket classification.
Make Change Impact Visible
Relationships also help identify the consequences of change.
A revised product configuration may affect the applicability of an earlier assessment. A corrected classification may warrant review of associated information determinations. A document may turn out to concern a different component than initially assumed.
A relational model allows the organization to identify potentially affected records and evaluate them.
That is a targeted reassessment process. It does not require assuming that every related determination must change.
Useful records preserve:
- The object and configuration assessed.
- The relationship used in the analysis.
- Its source and validation status.
- The related facts or determinations relied upon.
- The rule or policy version applied.
- The resulting decision and approval.
These connections make it easier to understand why an outcome was reached and whether its supporting conditions still hold.
Connect the Teams That Hold the Facts
Engineering, Manufacturing, Supply Chain, IT, and Export Controls each hold parts of the classification picture.
Engineering applications provide product structures and configuration history. Suppliers provide technical specifications and identity information. Software teams maintain functionality and release records. Export specialists establish the regulatory reasoning and evidence requirements.
A practical classification architecture connects those contributions through persistent identifiers, maintained relationships, and clear responsibilities.
An ITC Engineering Workspace, supported by a governed Git ecosystem, can preserve the models, interpretations, rules, and tests developed through that collaboration. Authoritative engineering and operational records remain in the systems responsible for maintaining them.
See the Relationships Behind the Request
The individual classification request remains important. It is also an entry point into a larger population of related objects and evidence.
HEMSI provides a common way to organize that population. Engineering relationships and information associations establish relevant dependencies. Governed rulesets make those dependencies usable in repeatable classification decisions.
To scale export classification, understand what each object is, what it relates to, and how those relationships contribute to its determination.
Related reading
- Stop Looking at the Classification Elephant Through the Transactional Keyhole
- What Is Export Controlled Information—and Why Its Definition and Identity Matter
- Why International Trade Compliance Needs Its Own Git Ecosystem
Explore the classification dependencies in your environment
TC Engine helps teams analyze product and information populations, identify missing evidence, and develop supported classification rules and integrations.
Explore Export Classification Analytics & Automation · Discuss your priorities