Public Demo
You are welcome to explore this solution. Prior to official go-live, you may use it freely — however, your data may be lost in future updates. No guarantees or liability are given. Use at your own discretion.

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 spaces and vice versa.

Two sides of the match

  • On a resource, a criterion with a value is a capability: this space’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 space 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.