Category Registry
Overview
The category & specs registry is a powerful configuration system that helps you organize and validate your product data. It enables you to:
Define component categories with standardized attributes and specifications
Import pre-built category templates from Duro's standard library
Create custom validation rules and constraints for your parts data
Establish consistent part numbering schemes across your library
Enforce data quality standards through automated validation
This registry serves as the foundation for maintaining clean, well-structured product data that can scale with your organization.
Schema
The category & specs registry is defined in a YAML file that is used to define the relationships between your part specifications and their constraints (ie. validation rules).
As a Library Registry Maintainer, you'll have the ability to define, override, and extend the structure of your library parts, and author custom validations on the specification values directly or in relation to other specifications.
Import Default Category Sets
Import pre-defined category sets from Duro to leverage existing definitions.
uses:
- duro/mechanical-categories@v1
- duro/[email protected]
Exclude Specific Categories
Selectively exclude specific categories from imported sets that aren't relevant to your library.
excludes:
- "Basic Electrical Component" # Excludes category with name "Basic Electrical Component"
- "Capacitance" # Excludes category with name "Capacitance"
Define Common Specifications
Create reusable specifications that can be referenced across multiple categories. Common specs are organized in a hierarchical structure:
commonSpecs:
dimensions:
standard_length:
name: "Length"
type: "string"
validation:
pattern: "^\\d+(\\.\\d+)?\\s*(mm|cm|m|in)$"
description: "Must be a number followed by a valid unit"
standard_width:
name: "Width"
type: "string"
validation:
pattern: "^\\d+(\\.\\d+)?\\s*(mm|cm|m|in)$"
description: "Must be a number followed by a valid unit"
Define Custom Categories
Create new categories with specific attributes and specifications.
categories:
- code: "920"
type: ASSEMBLY
name: Cable Assembly
shortName: CABLE
unitOfMeasure: EACH
specs:
- $ref: "#/commonSpecs/dimensions/standard_length"
required: "*"
- name: Conductors
type: integer
required: "*"
validation:
minimum: 1
maximum: 100
description: "Number of conductors (1-100)"
Define Category Type Specifications
Apply common specifications across all categories of a specific type. This helps maintain consistency and reduces repetition in your category definitions.
categoryTypeSpecs:
ASSEMBLY:
- $ref: "#/commonSpecs/dimensions/*" # Reference all dimension specs
required: "Prototype"
- $ref: "#/commonSpecs/physical/weight"
required: Production
severity: Warning
ELECTRICAL:
- $ref: "#/commonSpecs/electrical/*" # Reference all electrical specs
- $ref: "#/commonSpecs/quality/iso_certification"
required: Production
You can:
Reference entire specification groups using wildcards (
/*
)Reference individual specifications
Set default required stages and severity levels
Apply specifications across all categories of a specific type
This is particularly useful when:
You want to enforce standard specifications across category types
You need to maintain consistent validation rules
You want to reduce repetition in your category definitions
Implement Validation Rules
Define validation rules for specifications using different data types and formats.
specs:
- name: Voltage
type: string
validation:
pattern: "^\\d+(\\.\\d+)?\\s*V$"
description: "Must be a number followed by V (e.g., 5V, 3.3V)"
- name: PPAPLevel
type: integer
validation:
minimum: 1
maximum: 5
description: "Production Part Approval Process level (1-5)"
- name: Material
type: string
validation:
enum: [Plastic, Metal, Glass, Ceramic, Wood, Composite]
description: "Must be one of the specified materials"
Specify Lifecycle Requirements
Define when specifications are required based on the item's lifecycle stage.
specs:
- name: NetsuiteItemId
type: string
required: "Production"
validation:
pattern: "^NS-\\d{8}$"
description: "Must be NS- followed by 8 digits"
- name: IONProcessTemplate
type: string
required: "Design"
severity: "Warning"
validation:
pattern: "^TPL-[A-Z0-9]{8}$"
Extend Existing Categories
Extend pre-defined categories with additional specifications or modifications.
categories:
- extends: duro/mechanical-categories/[email protected]
name: Custom Bearing # change the name for this category
specs:
- name: Surface Treatment
type: string
required: Production
validation:
enum: [Chrome, Nickel, Phosphate, None]
Reference Common Specifications
Reuse common specifications across different categories using references.
specs:
- $ref: "#/commonSpecs/dimensions/standard_length"
required: "*"
- $ref: "#/commonSpecs/electrical/operating_temp_max"
required: "Design"
Import External Specifications
Use specifications defined in external libraries.
specs:
- $ref: "duro/electrical-categories/specs/voltage/input_voltage"
required: Design
Import Entire Specification Sets
Import all specifications from a set using the wildcard (*) operator. This is useful when you need to include an entire group of related specifications.
specs:
# Imports all dimension specifications from Duro's mechanical specs
- $ref: "duro/mechanical-categories/specs/dimensions/*"
required: Prototype
# This will include Height, Width, Length, Thickness, etc. as defined in the Duro specs
# Each imported spec will maintain its validation rules while inheriting the required status
The wildcard import is particularly powerful when:
You need all specifications from a logical grouping
You want to maintain consistency with a standard specification set
You want to reduce repetitive references to individual specifications
Define Warning-Level Requirements
Specify requirements that trigger warnings rather than errors when not met.
specs:
- name: ERPCostCenter
type: string
required: "In Review"
severity: "Warning"
validation:
pattern: "^CC-[A-Z]{2}-\\d{4}$"
Create Integration Points
Define specifications for integration with external systems.
specs:
- name: JiraECO
type: string
validation:
pattern: "^ECO-\\d{4}$"
description: "Jira ECO number"
- name: SAPMaterialNumber
type: string
validation:
pattern: "^\\d{9}$"
description: "Must be exactly 9 digits"
Define Quality Control Requirements
Specify quality-related specifications and their validation rules.
specs:
- name: QualityInspectionFreq
type: string
required: "Production"
validation:
enum: [PerBatch, PerShift, Daily, Weekly, Monthly]
description: "Frequency of quality inspections"
- name: ISOCertification
type: string
required: "In Review"
severity: "Warning"
validation:
pattern: "^ISO\\d{4,5}:\\d{4}$"
description: "ISO certification number and year"
Available Category Types
Define the type of category being created. The type affects validation rules and available specifications.
categories:
- code: "920"
# Available types:
type: MECHANICAL # For mechanical parts and assemblies
# OR
type: ELECTRICAL # For electrical components
# OR
type: ASSEMBLY # For combined assemblies
# OR
type: DOCUMENT # For documentation
# OR
type: SOFTWARE # For software components
Validation Types Reference
Define specifications using different validation types and formats.
String Validation
commonSpecs:
validation:
# Pattern-based string validation
- name: PartNumber
type: string
validation:
pattern: "^[A-Z]{2}-\\d{6}$"
description: "Must be 2 capital letters followed by 6 digits"
# Enum-based string validation
- name: Material
type: string
validation:
enum: [Plastic, Metal, Glass, Ceramic]
description: "Must be one of the allowed materials"
# Unit-based measurements
- name: Length
type: string
validation:
pattern: "^\\d+(\\.\\d+)?\\s*(mm|cm|m|in)$"
description: "Number with valid unit (e.g., 10mm, 2.5cm)"
Integer Validation
commonSpecs:
validation:
# Range-based integer validation
- name: Quantity
type: integer
validation:
minimum: 1
maximum: 1000
description: "Must be between 1 and 1000"
# Simple integer validation
- name: PinCount
type: integer
validation:
minimum: 1
description: "Must be at least 1"
Paired Field Validation
commonSpecs:
dimensions:
- name: Height
type: paired
components:
value:
name: "Height Value"
type: integer
validation:
minimum: 0
maximum: 999999
description: "Numeric value for height"
unit:
name: "Height Unit"
type: string
validation:
enum: ["mm", "cm", "m", "in"]
description: "Unit for height measurement"
display: "{value}{unit}"
Conditional Validation
commonSpecs:
conditional:
# Example 1: Range-based conditional validation
- name: ColorRange
type: conditional
components:
color:
name: "Color"
type: string
validation:
enum: ["red", "blue", "green"]
description: "Color selection"
range:
name: "Range Value"
type: integer
validation:
description: "Range value"
conditions:
- when: "color == 'red'"
minimum: 1
maximum: 20
- when: "color == 'blue'"
minimum: 21
maximum: 40
- when: "color == 'green'"
minimum: 41
maximum: 50
# Example 2: Enum-based conditional validation
- name: Food Dye Color
type: conditional
display: "{baseColor} {number}"
components:
baseColor:
name: "Base Color"
type: string
validation:
enum: [Red, Yellow, Blue, Green]
description: "Base color of the food dye"
number:
name: "Dye Number"
type: integer
validation:
description: "FDA approved dye number for the selected color"
conditions:
- when: "baseColor == 'Red'"
enum: [3, 40]
- when: "baseColor == 'Yellow'"
enum: [5, 6]
- when: "baseColor == 'Blue'"
enum: [1, 2]
- when: "baseColor == 'Green'"
enum: [3]
The conditional validation supports two types of validation rules:
Range-based conditions: Define minimum and maximum values based on another field's value
Enum-based conditions: Define specific allowed values based on another field's value
You can also specify a display format using the display
property, which determines how the combined values should be presented. For example, "{baseColor} {number}"
will show values like "Red 40" or "Yellow 5".
Version Format Reference
When referencing external categories or specifications, you can use different version formats:
uses:
# Full semantic version
- duro/[email protected]
# Minor version only (equivalent to latest patch)
- duro/[email protected]
# Major version only (equivalent to latest minor.patch)
- duro/software-categories@v1
Note: Using shorter versions will automatically use the latest compatible version within that scope.
Last updated