Criteria and capabilities

Define the reusable, typed attributes that drive capability matching — data types, units, enums, and applicability.

Published · Updated

Settings → Criteria (“Define reusable criteria that can be used as space capabilities or utilization requirements. These criteria enable automatic validation during utilization.”) is the definition side of capability matching. Everything here needs the Editor role or above.

Creating a criterion

Add Criterion opens the dialog:

  • Name — how it reads everywhere: on resources, on requests, in conflict messages. E.g. Project Management, Max Load (kg).
  • Data Type — one of five:
    • Boolean (true/false) — present or absent.
    • Number (numeric value) — a magnitude; give it a Unit (kg, m², kW) so values read unambiguously.
    • String (text) — free-form text.
    • Enum (predefined options) — a fixed list of values you define in the enum editor.
    • Date (calendar date) — a single day, for things like a next-inspection or certification-expiry date.
  • Description — what this criterion represents, for future editors.
  • Applies to — which resource types may carry it (“Select at least one resource domain this criterion applies to”). The list is every active resource type, so a person-only skill never clutters a machine’s capability picker and a Mileage criterion can be scoped to cars alone.

Criteria are the vocabulary scheduling matches on. Whatever a request can ask for, and whatever a resource can offer, is a criterion. Values are checked server-side against the criterion’s data type whenever a resource is saved, and a mismatch is reported by name (‘Max Load (kg)’ expects a number).

To record something the scheduler never matches on — a serial number, a manual link, a spindle speed — use a custom field on the resource type instead. See Resource types.

Editing and the lock

Open a criterion to edit its details. One rule protects your data: once a criterion has recorded values, its data type is locked — “Data type is locked because this criterion has existing values.” Changing Boolean to Number under live capabilities would corrupt their meaning, so Orkyo forbids it. Add a new criterion instead and migrate deliberately.

Deletion follows the same logic: a criterion in use cannot be deleted (“Cannot delete: this criterion has existing values”).

Where criteria are consumed

  • Capabilities — on stations (Stations), on people as skills (People), on the resources of any type you defined (Custom resource types), and on groups, where members inherit them.
  • Requirements — on requests, gating placement and auto-scheduling.
  • Templates — request templates pre-bundle criteria values for recurring work.
  • Validation and conflicts — mismatches surface by criterion name.

Filtering and transport

The list filters by applicability tab — All, then one tab per active resource type — so large vocabularies stay navigable per domain. With this page open, the top bar’s Export/Import move criteria definitions as CSV or JSON — and Presets carry criteria along with groups and templates as one configuration unit.

For a worked setup — including an enum and a numeric threshold, verified against real placements — follow Match requests to the right resources.