How capability matching works

One criteria vocabulary, used as capabilities on resources and requirements on requests — and validated automatically.

Published

Capability matching is the mechanism that keeps schedules honest: work only lands on resources that can actually host it. It rests on a single idea — capabilities and requirements are the same criteria, viewed from two sides.

Criteria: one vocabulary, typed

A criterion is defined once, in Settings → Criteria, with a Data Type:

  • Boolean (true/false) — the resource has it or it doesn’t: Crane, Cleanroom certified.
  • Number (numeric value) — a magnitude, optionally with a Unit: Max Load (kg), Capacity.
  • String (text) — free-form values.
  • Enum (predefined options) — one of a fixed list you define: Voltage: 230V / 400V.

Each criterion declares what it Applies to — which resource domains may carry it — so person-only attributes never show up on machines and vice versa.

Two sides of the match

  • On a resource, a criterion with a value is a capability: this cell’s Capacity is 24, this person holds Forklift license. Groups can carry capabilities too, which their members share.
  • On a request, a criterion with a value is a requirement: this job needs Capacity of at least 16 and Forklift license.

Because both sides speak the same vocabulary, matching is mechanical: a resource satisfies a requirement when it carries the criterion with a compatible value. There is no separate tagging scheme to keep in sync.

Where matching acts

  • Scheduling manually — when you place a request, Orkyo validates the placement and lists concrete issues by name, e.g. Required capability missing, Resource is overbooked, Overlaps with off-time, Resource type mismatch.
  • Auto-scheduling — the solver only considers resources whose capabilities satisfy the request’s requirements; a request no resource can satisfy comes back as No compatible resource in the auto-schedule preview.
  • After the fact — edits ripple. Remove a capability a scheduled request depends on and a conflict appears; see Understanding conflicts.

Designing a good criteria set

  • Start small. A handful of criteria that genuinely gate placements beats a taxonomy nobody maintains. You can add more at any time.
  • Prefer Boolean and Enum where possible — they are unambiguous to match and to read.
  • Use Number for real thresholds (capacity, load, power) and give it a unit.
  • Name for the shop floor, not the database: Forklift license reads better on a conflict message than cert_fl_class1.

Setting this up end to end — criteria, capabilities, a requirement, and a verified match — is the subject of Match requests to the right resources.