# End-to-End Example: Deriving Requirements from a UHT Code
This example demonstrates how to generate system requirements by decomposing a 32-bit Universal Hex Taxonomy (UHT) code. The process illustrates how the presence of semantic traits can be used to define structured, explainable requirements.
---
## System Description
**System:** Motion-Activated Light
**Overview:** A ceiling-mounted device that detects motion and activates a light in response.
---
## Step 1: Trait Selection
Based on the system's properties, the following UHT traits apply:
| Trait # | Trait Name | Justification |
|---------|--------------------------------------|---------------|
| 1 | Physical object | The device has a tangible form. |
| 2 | Man-made / synthetic | It is manufactured. |
| 6 | Perceptible | It emits visible light. |
| 7 | Material form | It is a discrete hardware unit. |
| 9 | Purposeful / intentional | It serves a defined function. |
| 10 | Emits output / produces effect | The system emits light. |
| 11 | Processes or regulates logic/signals | Motion triggers an internal logic path. |
| 13 | Interacts with humans directly | It responds to human movement. |
| 14 | Part of a larger system | Integrates into electrical infrastructure. |
| 21 | Behavior-guiding | It enforces usage assumptions. |
| 28 | Regulated / governed | Must meet safety or electrical standards. |
---
## Step 2: Encode UHT Code
The presence of the above traits corresponds to the following binary representation:
Bitstring: 11000011 01111100 00000000 00000100
Hex code: C3 7C 00 04
---
## Step 3: Trait-Based Requirement Derivation
Each selected trait implies a specific requirement for the system:
| Trait | Derived Requirement |
|-------|---------------------|
| Physical object | The device must have a tangible, mountable form. |
| Man-made / synthetic | The device must be constructed from manufactured components. |
| Perceptible | The device must emit light that is visible to users. |
| Material form | The device must be physically discrete and installable. |
| Purposeful / intentional | The device must activate illumination in response to motion. |
| Emits output / produces effect | The device must emit light as its output. |
| Processes or regulates logic/signals | The device must detect motion and trigger a corresponding response. |
| Interacts with humans directly | The device must respond to human presence or movement. |
| Part of a larger system | The device must be capable of integrating into an electrical or home automation system. |
| Behavior-guiding | The device should support assumptions related to occupancy and usage patterns. |
| Regulated / governed | The device must comply with relevant safety or electrical standards. |
---
## Step 4: Output as a Self-Describing Requirement Object
```json
{
"entity": "Motion-Activated Light",
"uht": "C3 7C 00 04",
"traits": [
"Physical object",
"Man-made / synthetic",
"Perceptible",
"Material form",
"Purposeful / intentional",
"Emits output / produces effect",
"Processes or regulates logic/signals",
"Interacts with humans directly",
"Part of a larger system",
"Behavior-guiding",
"Regulated / governed"
],
"derived_requirements": [
"The device must have a tangible, mountable form.",
"The device must be constructed from manufactured components.",
"The device must emit light that is visible to users.",
"The device must be physically discrete and installable.",
"The device must activate illumination in response to motion.",
"The device must emit light as its output.",
"The device must detect motion and trigger a corresponding response.",
"The device must respond to human presence or movement.",
"The device must be capable of integrating into an electrical or home automation system.",
"The device should support assumptions related to occupancy and usage patterns.",
"The device must comply with relevant safety or electrical standards."
]
}
```
# Summary
This example demonstrates how UHT can serve as a foundation for generating structured, self-describing requirements. By selecting traits based on system identity, a compact semantic code is produced, from which functional and regulatory expectations can be derived. This approach supports explainability, traceability, and integration within technical systems design.