Requirements

A requirement is one atomic, testable statement about an asset. It describes what must be true, why it matters, and which validator can report pass or failure for that rule.

For the factory profile, the custom requirement is: every boundable prim must fit inside the configured bounding-box dimensions.

Required Sections

Every requirement Markdown file has:

• a level-1 title

• a metadata table with Code, Version, Compatibility, Validator, and Tags

• a Summary section

The Code is local to the authoring package until code generation qualifies it with --reverse-domain.

Metadata

| Code          | GEOMETRY.001             |
|---------------|--------------------------|
| Version       | 1.0.0                    |
| Compatibility | {compatibility}`OpenUSD` |
| Validator     | FactoryBoundsChecker     |
| Tags          | {tag}`correctness`       |

Use Validator as documentation metadata for the rule that enforces the requirement. Generated Python requirement objects are bound to rules by the validation plugin with register_requirements(...).

Parameters

Requirement parameters define values that validation rules can read through self.parameters. They are the right place for factory-specific bounding-box limits because different production lines can use different dimensions without changing the rule code.

## Parameters

| Parameter    | Type  | Default Value |
|--------------|-------|---------------|
| MAX_X_METERS | float | 6.0           |
| MAX_Y_METERS | float | 6.0           |
| MAX_Z_METERS | float | 4.0           |

Supported parameter types are int, bool, float, and enum("A", "B", "C"). Default values are parsed into the generated package and can be overridden at runtime.

Optional Sections

Use optional sections to make the requirement actionable:

• Description explains the validation criteria.

• Why is it required? records the operational reason for the requirement.

• Examples shows valid and invalid asset snippets.

• How to comply gives asset authors direct remediation steps.

• For More Information links to external references.

Complete Example

# factory-boundable-size

| Code          | GEOMETRY.001             |
|---------------|--------------------------|
| Version       | 1.0.0                    |
| Compatibility | {compatibility}`OpenUSD` |
| Validator     | FactoryBoundsChecker     |
| Tags          | {tag}`correctness`       |

## Summary

Factory assets must fit within the configured bounding-box dimensions.

## Description

The validator computes each boundable prim's world-space bounding box and compares its size to the configured factory
limits. The default values below describe the placement envelope for one factory line in meters.

## Parameters

| Parameter    | Type  | Default Value |
|--------------|-------|---------------|
| MAX_X_METERS | float | 6.0           |
| MAX_Y_METERS | float | 6.0           |
| MAX_Z_METERS | float | 4.0           |

## Why is it required?

- Prevents oversized assets from blocking automated placement.
- Catches unit-scale mistakes before assets reach assembly scenes.
- Keeps factory layout validation aligned with the physical production cell.

## Examples

### Invalid: oversized fixture

```usd
#usda 1.0
(
    metersPerUnit = 1
)

def Cube "OversizedFixture"
{
    double size = 8
}
```

### Valid: bounded fixture

```usd
#usda 1.0
(
    metersPerUnit = 1
)

def Cube "Fixture"
{
    double size = 2
}
```

## How to comply

- Confirm `metersPerUnit` matches the source asset's authored unit scale.
- Split large equipment into separately placed assets when the factory workflow expects modular props.
- Reduce unused geometry, collision, or visualization extents that inflate the computed bounding box.