systemlink-cli 1.3.1__py3-none-any.whl

slcli/skills/slcli/references/analysis-recipes.md

@@ -0,0 +1,474 @@
+# Analysis Recipes
+
+Step-by-step recipes for answering common data analysis questions with `slcli`.
+Each recipe maps to a real-world scenario and shows the exact commands needed.
+
+---
+
+## Recipe 1: Operator failure rate analysis
+
+**Question:** Which operators have the highest failure rates and what should they
+focus on?
+
+**Steps:**
+
+```bash
+# Step 1: Get summary by operator to see total counts per operator
+slcli testmonitor result list --summary --group-by operator -f json
+
+# Step 2: Get failed counts per operator
+slcli testmonitor result list --status FAILED --summary --group-by operator -f json
+
+# Step 3: Deep-dive into a specific operator's failures
+slcli testmonitor result list --operator "xli" --status FAILED -f json --take 500
+
+# Step 4: See which programs the operator fails on most
+slcli testmonitor result list --operator "xli" --status FAILED --summary --group-by programName -f json
+```
+
+**Post-processing with jq:**
+
+```bash
+# Calculate failure rate per operator (combine step 1 and 2 outputs)
+slcli testmonitor result list --operator "xli" -f json --take 500 | \
+  jq '[group_by(.status.statusType) | .[] | {status: .[0].status.statusType, count: length}]'
+```
+
+---
+
+## Recipe 2: Calibration overdue tracking
+
+**Question:** Which assets are most overdue for calibration and what test
+capacity is at risk?
+
+**Steps:**
+
+```bash
+# Step 1: List all assets past calibration due date
+slcli asset list --calibration-status PAST_RECOMMENDED_DUE_DATE -f json --take 100
+
+# Step 2: Get the fleet-wide calibration summary
+slcli asset summary -f json
+
+# Step 3: Check assets approaching due date (proactive)
+slcli asset list --calibration-status APPROACHING_RECOMMENDED_DUE_DATE -f json
+
+# Step 4: Get calibration history for a specific overdue asset
+slcli asset calibration <ASSET_ID> -f json
+
+# Step 5: Check which system the asset belongs to
+slcli asset location-history <ASSET_ID> -f json
+```
+
+**Post-processing with jq:**
+
+```bash
+# Group overdue assets by model
+slcli asset list --calibration-status PAST_RECOMMENDED_DUE_DATE -f json --take 200 | \
+  jq '[group_by(.modelName) | .[] | {model: .[0].modelName, count: length}] | sort_by(-.count)'
+
+# Find overdue assets in connected systems (blocking test execution)
+slcli asset list --calibration-status PAST_RECOMMENDED_DUE_DATE --connected -f json --take 200 | \
+  jq 'length'
+```
+
+---
+
+## Recipe 3: Test time distribution and bottleneck identification
+
+**Question:** What is the test time distribution across stations and where are
+bottlenecks?
+
+**Steps:**
+
+```bash
+# Step 1: Get results with execution time, grouped by host
+slcli testmonitor result list -f json --take 500 --order-by TOTAL_TIME_IN_SECONDS --descending
+
+# Step 2: Summarize by host to find busiest stations
+slcli testmonitor result list --summary --group-by hostName -f json
+
+# Step 3: Drill into slowest host
+slcli testmonitor result list --host-name "station-01" -f json --take 200 \
+  --order-by TOTAL_TIME_IN_SECONDS --descending
+```
+
+**Post-processing with jq:**
+
+```bash
+# Calculate average test duration per host
+slcli testmonitor result list -f json --take 1000 | \
+  jq '[group_by(.hostName) | .[] | {
+    host: .[0].hostName,
+    count: length,
+    avg_seconds: ([.[].totalTimeInSeconds] | add / length),
+    max_seconds: ([.[].totalTimeInSeconds] | max)
+  }] | sort_by(-.avg_seconds)'
+
+# Find outlier tests (> 2x average duration)
+slcli testmonitor result list -f json --take 1000 | \
+  jq '(([.[].totalTimeInSeconds] | add / length) * 2) as $threshold |
+      [.[] | select(.totalTimeInSeconds > $threshold)] | length'
+```
+
+---
+
+## Recipe 4: System capability discovery
+
+**Question:** Which connected systems lack specific measurement capabilities?
+
+**Steps:**
+
+```bash
+# Step 1: List all connected systems
+slcli system list --state CONNECTED -f json --take 200
+
+# Step 2: Get assets for a specific system (new: single command)
+slcli system get <SYSTEM_ID> --include-assets -f json | jq '._assets.items'
+
+# Step 3: Generate a hardware report
+slcli system report --type HARDWARE -o hardware_report.csv
+
+# Step 4: Check systems with specific packages
+slcli system list --has-package "DAQmx" --state CONNECTED -f json
+```
+
+**Post-processing with jq:**
+
+```bash
+# List connected systems and their OS
+slcli system list --state CONNECTED -f json --take 500 | \
+  jq '[.[] | {alias, id, os: .grains.kernel}]'
+```
+
+---
+
+## Recipe 4b: Full system health snapshot
+
+**Question:** What is the current health of a specific system — assets, alarms, recent jobs, test results, scheduled work?
+
+**Answer:** Use `--include-all` (or selective `--include-*` flags) to fetch all related
+resources in a single parallel call, mirroring the web UI system detail page.
+
+```bash
+# Full snapshot in table format
+slcli system get <SYSTEM_ID> --include-all
+
+# Limit each section to 5 rows / extend work-item window to 60 days
+slcli system get <SYSTEM_ID> --include-all -t 5 --workitem-days 60
+
+# Machine-readable JSON — all sections embedded
+slcli system get <SYSTEM_ID> --include-all -f json
+
+# Extract just the active alarms
+slcli system get <SYSTEM_ID> --include-alarms -f json | jq '._alarms.items'
+
+# Show systems that have active alarms
+slcli system list --state CONNECTED -f json --take 200 | \
+  jq -r '.[].id' | \
+  xargs -I{} sh -c \
+    'slcli system get {} --include-alarms -f json | jq -e "._alarms.totalCount > 0" > /dev/null && echo {}'
+```
+
+**JSON output shape** — each included section is nested under `_<section>`:
+
+```json
+{
+  "id": "...",
+  "_assets":    { "totalCount": 3, "items": [...], "error": null },
+  "_alarms":    { "totalCount": 1, "items": [...], "error": null },
+  "_jobs":      { "totalCount": 5, "items": [...], "error": null },
+  "_results":   { "totalCount": 12, "items": [...], "error": null },
+  "_states":    { "totalCount": 2, "items": [...], "error": null },
+  "_workitems": { "totalCount": 0, "items": [], "error": null }
+}
+```
+
+> If a service is unavailable, `"error"` contains the error message and the
+> other sections still render normally.
+
+---
+
+## Recipe 5: Product yield analysis
+
+**Question:** How many units per product variant are past their first-pass yield
+expectations?
+
+**Steps:**
+
+```bash
+# Step 1: List products with battery part numbers
+slcli testmonitor product list --part-number "BATT" -f json
+
+# Step 2: Get summary for a specific product
+slcli testmonitor product list --part-number "BATT-8" --summary -f json
+
+# Step 3: Get pass/fail breakdown for a product
+slcli testmonitor result list --part-number "BATT-8" --summary --group-by status -f json
+
+# Step 4: Compare across all battery products
+for i in $(seq 0 14); do
+  echo "BATT-$i:"
+  slcli testmonitor result list --part-number "BATT-$i" --summary --group-by status -f json
+done
+```
+
+**Post-processing with jq:**
+
+```bash
+# Calculate yield rate for a part number
+slcli testmonitor result list --part-number "BATT-8" -f json --take 1000 | \
+  jq '{
+    total: length,
+    passed: [.[] | select(.status.statusType == "PASSED")] | length,
+    failed: [.[] | select(.status.statusType == "FAILED")] | length
+  } | . + {yield_pct: (100 * .passed / .total | round)}'
+```
+
+---
+
+## Recipe 6: Test program runtime analysis
+
+**Question:** Which test programs have the longest runtimes?
+
+**Steps:**
+
+```bash
+# Step 1: Summarize by program name
+slcli testmonitor result list --summary --group-by programName -f json
+
+# Step 2: Get detailed results for the longest program
+slcli testmonitor result list --program-name "SOH_SCT_HPPC" -f json --take 200 \
+  --order-by TOTAL_TIME_IN_SECONDS --descending
+
+# Step 3: Compare program variants
+slcli testmonitor result list --program-name "SOH_SCT_HPPC_0" -f json --take 100
+slcli testmonitor result list --program-name "SOH_SCT_HPPC_5" -f json --take 100
+```
+
+**Post-processing with jq:**
+
+```bash
+# Top 5 programs by average runtime
+slcli testmonitor result list -f json --take 2000 | \
+  jq '[group_by(.programName) | .[] | {
+    program: .[0].programName,
+    count: length,
+    avg_seconds: ([.[].totalTimeInSeconds] | add / length | . * 100 | round / 100),
+    total_hours: ([.[].totalTimeInSeconds] | add / 3600 | . * 100 | round / 100)
+  }] | sort_by(-.avg_seconds) | .[:5]'
+```
+
+---
+
+## Recipe 7: Location-based failure analysis
+
+**Question:** Are there facility-specific issues causing higher failure rates?
+
+**Steps:**
+
+```bash
+# Step 1: List all systems to understand location naming conventions
+slcli system list -f json --take 200 | jq '[.[].alias] | unique'
+
+# Step 2: Get failure counts per system
+slcli testmonitor result list --status FAILED --summary --group-by systemId -f json
+
+# Step 3: Get total counts per system for rate calculation
+slcli testmonitor result list --summary --group-by systemId -f json
+
+# Step 4: Drill into a system with high failure rate
+slcli testmonitor result list --system-id "<SYSTEM_ID>" --status FAILED -f json --take 100
+```
+
+---
+
+## Recipe 8: Fixture calibration and capacity planning
+
+**Question:** Which PAtools fixtures need recalibration soon and what capacity
+would we lose?
+
+**Steps:**
+
+```bash
+# Step 1: List all PAtools fixtures
+slcli asset list --filter 'VendorName.Contains("PAtools")' --asset-type FIXTURE -f json
+
+# Step 2: Filter for those approaching calibration due date
+slcli asset list --filter 'VendorName.Contains("PAtools")' --asset-type FIXTURE \
+  --calibration-status APPROACHING_RECOMMENDED_DUE_DATE -f json
+
+# Step 3: Get overall fixture summary
+slcli asset summary -f json
+```
+
+**Post-processing with jq:**
+
+```bash
+# Count fixtures by calibration status
+slcli asset list --filter 'VendorName.Contains("PAtools")' --asset-type FIXTURE -f json --take 100 | \
+  jq '[group_by(.calibrationStatus) | .[] | {status: .[0].calibrationStatus, count: length}]'
+```
+
+---
+
+## Recipe 9: Product family workload distribution
+
+**Question:** How is test execution distributed across product families?
+
+**Steps:**
+
+```bash
+# Step 1: List all products to see families
+slcli testmonitor product list -f json --take 100
+
+# Step 2: Summarize by product family
+slcli testmonitor product list --summary -f json
+
+# Step 3: Get result volume per part number
+slcli testmonitor result list --summary --group-by programName -f json
+```
+
+**Post-processing with jq:**
+
+```bash
+# Group products by family prefix
+slcli testmonitor product list -f json --take 100 | \
+  jq '[group_by(.family) | .[] | {family: .[0].family, products: length}] | sort_by(-.products)'
+
+# Get execution volume grouped by part-number prefix
+slcli testmonitor result list -f json --take 2000 | \
+  jq '[group_by(.partNumber | split("-")[0]) | .[] | {
+    family: .[0].partNumber | split("-")[0],
+    executions: length,
+    total_hours: ([.[].totalTimeInSeconds] | add / 3600 | . * 10 | round / 10)
+  }] | sort_by(-.executions)'
+```
+
+---
+
+## Recipe 10: Environmental condition failure patterns
+
+**Question:** Are failures concentrated in specific operating condition ranges?
+
+**Steps:**
+
+```bash
+# Step 1: Get failed results with properties
+slcli testmonitor result list --status FAILED -f json --take 500
+
+# Step 2: Get detailed result with step data for environmental readings
+slcli testmonitor result get <RESULT_ID> --include-steps -f json
+
+# Step 3: Compare passed vs. failed property distributions
+slcli testmonitor result list --status PASSED -f json --take 500
+slcli testmonitor result list --status FAILED -f json --take 500
+```
+
+**Post-processing with jq:**
+
+```bash
+# Extract temperature and voltage from failed results
+slcli testmonitor result list --status FAILED -f json --take 500 | \
+  jq '[.[] | select(.properties != null) | {
+    partNumber,
+    programName,
+    properties: (.properties | to_entries | map(select(.key | test("Temp|Volt|Capacity"; "i"))))
+  }] | [.[] | select(.properties | length > 0)]'
+
+# Compare property distributions between passed and failed
+slcli testmonitor result list --status FAILED --part-number "BATT-8" -f json --take 200 | \
+  jq '[.[].totalTimeInSeconds] | {min: min, max: max, avg: (add / length | round)}'
+```
+
+---
+
+## Recipe 11: Create and schedule a work item on a specific fixture/slot and system
+
+**Question:** "Create a work item for final validation testing, and schedule it on the
+slot(s) belonging to Chamber B for all day tomorrow."
+
+**Concept:** In SystemLink, a _slot_ is an asset with `assetType = FIXTURE`. "Chamber B"
+is most likely a registered system (found via `slcli system list`) whose associated
+fixture assets (the test slots inside it) are of type FIXTURE. The work item template
+defines named resource requirement slots (e.g. "System Under Test", "Chamber") which are
+filled by assigning real asset IDs or system IDs at scheduling time.
+
+**Steps:**
+
+```bash
+# Step 1: Find Chamber B's system ID
+slcli system list --alias "Chamber B" -f json | jq -r '.[0].id'
+# → e.g. "chamber-b-minion-id"
+
+# Step 2: Find fixture/slot assets belonging to Chamber B
+#   Fixtures are assets with assetType = FIXTURE located on the Chamber B system
+slcli asset list --asset-type FIXTURE -f json | \
+  jq '[.[] | select(.location.minionId == "chamber-b-minion-id")]'
+# → e.g. [ { "id": "fixture-slot-1", "name": "Slot 1" }, ... ]
+
+# Step 3: Find a suitable work item template (if creating from template)
+slcli workitem template list -f json | \
+  jq '[.[] | select(.name | test("validation"; "i")) | {id, name}]'
+# → e.g. "template-abc"
+
+# Step 4: Create the work item
+slcli workitem create-from-template template-abc \
+  --name "Final Validation - Chamber B" \
+  --state NEW \
+  -f json | jq -r '.id'
+# → e.g. "wi-12345"
+# Or create from scratch:
+slcli workitem create \
+  --name "Final Validation - Chamber B" \
+  --type testplan \
+  --state NEW \
+  --part-number "P-FINAL-001" \
+  -f json | jq -r '.id'
+
+# Step 5: Schedule the work item — assign Chamber B system + fixture slots,
+#          and set tomorrow's date (00:00–23:59 UTC)
+slcli workitem schedule wi-12345 \
+  --start "2026-03-03T00:00:00Z" \
+  --end   "2026-03-03T23:59:59Z" \
+  --system "chamber-b-minion-id" \
+  --fixture "fixture-slot-1" \
+  --fixture "fixture-slot-2"
+```
+
+**Multi-slot shorthand with shell expansion:**
+
+```bash
+# Find all fixture IDs for Chamber B and schedule them all at once
+FIXTURE_FLAGS=$(
+  slcli asset list --asset-type FIXTURE -f json | \
+    jq -r '[.[] | select(.location.minionId == "chamber-b-minion-id") | "--fixture", .id] | .[]'
+)
+slcli workitem schedule wi-12345 \
+  --start "2026-03-03T00:00:00Z" \
+  --end   "2026-03-03T23:59:59Z" \
+  --system "chamber-b-minion-id" \
+  $FIXTURE_FLAGS
+```
+
+**Key facts:**
+
+- `--system` takes a system/minion ID (from `slcli system list`).
+- `--fixture` takes an _asset_ ID of type FIXTURE (from `slcli asset list --asset-type FIXTURE`).
+- `--dut` takes an _asset_ ID of type DEVICE_UNDER_TEST.
+- All three flags are repeatable for multi-resource scheduling.
+- Time and resource flags can be combined in a single `workitem schedule` call.
+
+---
+
+## General tips
+
+- **Start with `--summary`** to understand data shape before fetching raw records.
+- **Use `--group-by`** with `--summary` for aggregation: `status`, `programName`,
+  `serialNumber`, `operator`, `hostName`, `systemId`.
+- **Chain with `jq`** for complex transformations — always use `-f json`.
+- **Use `--take` wisely** — start small (100-500), increase if needed.
+- **For rate calculations**, query total count and filtered count separately, then divide.
+- **Use `--order-by TOTAL_TIME_IN_SECONDS --descending`** to find slowest tests quickly.
+- **Asset `--connected` flag** limits to assets in currently connected systems.
+- **System `--has-package`** filter is client-side — use with `--state CONNECTED` to reduce volume.

slcli/skills/slcli/references/filtering.md

@@ -0,0 +1,236 @@
+# Filtering Reference
+
+Detailed guide to filtering syntax across slcli command groups.
+
+---
+
+## Convenience filters
+
+Convenience filters are named options that map to common query patterns. When
+multiple convenience filters are specified, they are combined with AND logic.
+
+### Test Monitor results
+
+| Flag                   | Match type | Example                    |
+| ---------------------- | ---------- | -------------------------- |
+| `--status TEXT`        | Exact      | `--status FAILED`          |
+| `--program-name TEXT`  | Contains   | `--program-name "SOH_SCT"` |
+| `--serial-number TEXT` | Contains   | `--serial-number "1234"`   |
+| `--part-number TEXT`   | Contains   | `--part-number "BATT-8"`   |
+| `--operator TEXT`      | Contains   | `--operator "xli"`         |
+| `--host-name TEXT`     | Contains   | `--host-name "station-01"` |
+| `--system-id TEXT`     | Exact      | `--system-id "abc-123"`    |
+| `--workspace, -w TEXT` | Name or ID | `--workspace "Production"` |
+
+### Test Monitor products
+
+| Flag                   | Match type | Example                    |
+| ---------------------- | ---------- | -------------------------- |
+| `--name TEXT`          | Contains   | `--name "Battery"`         |
+| `--part-number TEXT`   | Contains   | `--part-number "BATT"`     |
+| `--family TEXT`        | Contains   | `--family "Sensors"`       |
+| `--workspace, -w TEXT` | Name or ID | `--workspace "Production"` |
+
+### Assets
+
+| Flag                          | Match type     | Example                                          |
+| ----------------------------- | -------------- | ------------------------------------------------ |
+| `--model TEXT`                | Contains       | `--model "4071"`                                 |
+| `--serial-number TEXT`        | Exact          | `--serial-number "01BB877A"`                     |
+| `--bus-type CHOICE`           | Exact enum     | `--bus-type PCI_PXI`                             |
+| `--asset-type CHOICE`         | Exact enum     | `--asset-type FIXTURE`                           |
+| `--calibration-status CHOICE` | Exact enum     | `--calibration-status PAST_RECOMMENDED_DUE_DATE` |
+| `--connected`                 | Flag (boolean) | `--connected`                                    |
+| `--calibratable`              | Flag (boolean) | `--calibratable`                                 |
+| `--workspace, -w TEXT`        | Name or ID     | `--workspace "Production"`                       |
+
+### Systems
+
+| Flag                   | Match type             | Example                        |
+| ---------------------- | ---------------------- | ------------------------------ |
+| `--alias, -a TEXT`     | Contains               | `--alias "PXI"`                |
+| `--state CHOICE`       | Exact enum             | `--state CONNECTED`            |
+| `--os TEXT`            | Contains               | `--os "Windows"`               |
+| `--host TEXT`          | Contains               | `--host "lab-01"`              |
+| `--has-package TEXT`   | Contains (client-side) | `--has-package "DAQmx"`        |
+| `--has-keyword TEXT`   | Exact (repeatable)     | `--has-keyword "production"`   |
+| `--property TEXT`      | key=value (repeatable) | `--property "location=Austin"` |
+| `--workspace, -w TEXT` | Name or ID             | `--workspace "Production"`     |
+
+---
+
+## Advanced filter expressions
+
+Use `--filter` for complex queries that go beyond convenience filters.
+
+### Test Monitor LINQ syntax
+
+Test Monitor uses Dynamic LINQ filter expressions.
+
+```bash
+# Status filter
+--filter 'status.statusType == "FAILED"'
+
+# Combined filters
+--filter 'partNumber.Contains("ABC") and programName == "TestProgram"'
+
+# Date-based filtering
+--filter 'startedAt > DateTime(2026, 1, 1)'
+
+# Numeric comparison
+--filter 'totalTimeInSeconds > 300'
+```
+
+**Important:** Always use parameterized queries with `--substitution`:
+
+```bash
+# Good — parameterized
+--filter 'programName == @0' --substitution "SOH_SCT_HPPC_0"
+
+# Bad — string interpolation (security risk)
+--filter "programName = '${PROGRAM}'"
+```
+
+Multiple substitutions are positional:
+
+```bash
+--filter 'programName == @0 and operator == @1' \
+  --substitution "SOH_SCT_HPPC_0" \
+  --substitution "xli"
+```
+
+### Product filtering with `--product-filter`
+
+Filter results by properties of their associated product:
+
+```bash
+slcli testmonitor result list \
+  --product-filter 'family == @0' \
+  --product-substitution "Battery"
+```
+
+### Asset API expression syntax
+
+Asset filtering uses the Asset API expression language:
+
+```bash
+# Property access with methods
+--filter 'ModelName.Contains("PXI")'
+
+# Exact match
+--filter 'SerialNumber == "01BB877A"'
+
+# Combined with logical operators
+--filter 'BusType == "PCI_PXI" and CalibrationStatus == "OK"'
+
+# Vendor filtering
+--filter 'VendorName.Contains("PAtools")'
+
+# Combined with convenience filters
+slcli asset list --asset-type FIXTURE --filter 'VendorName.Contains("PAtools")'
+```
+
+### Systems Management filter syntax
+
+System filtering uses nested property access:
+
+```bash
+# Connection state (nested property)
+--filter 'connected.data.state == "CONNECTED"'
+
+# OS filtering
+--filter 'grains.data.kernel == "Windows"'
+
+# Combined
+--filter 'connected.data.state == "CONNECTED" and grains.data.kernel == "Windows"'
+
+# Alias matching
+--filter 'alias.Contains("PXI")'
+```
+
+---
+
+## Sorting
+
+Most list commands support `--order-by` and `--descending / --ascending`.
+
+### Test Monitor result sort fields
+
+`ID`, `STARTED_AT`, `UPDATED_AT`, `PROGRAM_NAME`, `SYSTEM_ID`, `HOST_NAME`,
+`OPERATOR`, `SERIAL_NUMBER`, `PART_NUMBER`, `TOTAL_TIME_IN_SECONDS`, `PROPERTIES`
+
+Default: `STARTED_AT` descending.
+
+```bash
+# Slowest tests first
+slcli testmonitor result list --order-by TOTAL_TIME_IN_SECONDS --descending
+
+# Oldest first
+slcli testmonitor result list --order-by STARTED_AT --ascending
+```
+
+---
+
+## Aggregation with --summary
+
+The `--summary` flag returns aggregate counts instead of individual records.
+Combine with `--group-by` for grouped aggregation.
+
+```bash
+# Total counts by status
+slcli testmonitor result list --summary --group-by status -f json
+
+# Counts by operator
+slcli testmonitor result list --summary --group-by operator -f json
+
+# Filtered summary — failures by program
+slcli testmonitor result list --status FAILED --summary --group-by programName -f json
+
+# Product summary
+slcli testmonitor product list --summary -f json
+```
+
+Available `--group-by` values: `status`, `programName`, `serialNumber`,
+`operator`, `hostName`, `systemId`.
+
+---
+
+## Pagination
+
+- **Table output**: Paginated interactively (default 25 rows, Y/n prompt for next page).
+- **JSON output**: Returns all results up to `--take` limit in a single array.
+- **`--take, -t`**: Controls maximum items. Default 25 for most commands, 100 for systems.
+
+```bash
+# Get exactly 500 results as JSON
+slcli testmonitor result list -f json --take 500
+
+# Get first 10 in table
+slcli testmonitor result list --take 10
+```
+
+---
+
+## Enum values reference
+
+### Status types (Test Monitor)
+
+`PASSED`, `FAILED`, `RUNNING`, `ERRORED`, `TERMINATED`, `TIMEDOUT`, `WAITING`,
+`SKIPPED`, `CUSTOM`
+
+### Calibration status (Assets)
+
+`OK`, `APPROACHING_RECOMMENDED_DUE_DATE`, `PAST_RECOMMENDED_DUE_DATE`,
+`OUT_FOR_CALIBRATION`
+
+### Asset types
+
+`GENERIC`, `DEVICE_UNDER_TEST`, `FIXTURE`, `SYSTEM`
+
+### Bus types (Assets)
+
+`BUILT_IN_SYSTEM`, `PCI_PXI`, `USB`, `GPIB`, `VXI`, `SERIAL`, `TCP_IP`, `CRIO`
+
+### System states
+
+`CONNECTED`, `DISCONNECTED`, `VIRTUAL`, `APPROVED`