The Orkyo planning model

Five ideas carry the whole product. Every page in Orkyo is a view onto some combination of them.

Requests — the work

A request is a piece of work to place onto your resources: a production run, a training session, a maintenance job. Requests carry:

• Requirements — criteria the hosting resource must satisfy (a minimum capacity, a certification, a piece of equipment).
• A schedule — a start and end once placed; unscheduled requests wait in the backlog.
• Constraints — optional time windows (“Earliest Start”, “Latest End”) limiting when the request may be scheduled.
• Children — requests nest. A parent acts as a container whose children can be bounded by a shared window, so a project’s tasks stay inside the project’s timeframe.
• Dependencies — what must finish first. Independent of the tree, because precedence crosses group and site boundaries. See Dependencies and the critical path.

Resources — the capacity

A resource is anything you schedule work onto or with. Orkyo has no built-in resource types: a workspace activates the kinds it runs from a catalog, or defines its own. See Type catalog.

Every type falls into one of two classes, and the class decides how the product treats it:

• Stations — resources with a fixed location. A mill, a cell, a bench. They carry a code, a capacity and a shape on the site plan, they belong to their site, and they cannot travel.
• Assets — resources that move. A person, a gauge, a forklift. They are planned by availability, and carry an allocation mode: Exclusive (one thing at a time) or Fractional (a percentage of their availability).

A type also carries fields of its own — what a mill records is not what a bench records — and can carry lists, such as a maintenance log per machine.

Resources are organized into groups — by site, team, or function — to keep large lists navigable and to manage related resources together.

Lists — the reference data

A list is rows and columns a workspace defines. Orkyo uses one mechanism for organization master data such as departments and job titles, for a log that belongs to one machine, and for a shared catalog several resources point at. A list column can reference another row of the same list, which is what makes a department tree a tree. See List definitions.

Criteria — the matching language

Criteria are typed attributes — Boolean, Number, String, or Enum — defined once in Settings and used on both sides of the match: on a resource they are capabilities (“this cell has a crane”), on a request they are requirements (“this job needs a crane”). One vocabulary, two roles. Criteria are what scheduling matches on; a type’s own fields record what a resource is, and are not matched. That is what lets Orkyo validate placements automatically. The details live in How capability matching works.

Sites — the geography

A site is a physical location: a plant, a campus, a building. Stations belong to sites; assets have a home site and can be marked available for other sites. The site selector in the top bar scopes the boards to one site, and scheduling settings — working hours, weekends, holiday regions — are defined per site.

Schedules — where it all meets

A schedule is the placement of requests onto resources over time. The Utilization board is where you build it — by dragging, or by letting auto-scheduling propose placements. When a placement violates the model — an overbooked resource, a missing capability, an absence — Orkyo raises a conflict rather than silently accepting it.

How the pieces mesh

Criteria ──── as capabilities ────▶ Resources (stations · assets)
   │                                    │  grouped, sited, with availability
   └──── as requirements ────▶ Requests │
                                   │    │
                                   ▼    ▼
                              Schedule (Utilization board)
                                   │
                                   ▼
                    Conflicts · Utilization · Insights

Define criteria first; describe resources with them; capture requests against them; schedule; let conflicts and insights tell you how reality is tracking the plan. That ordering is why the setup path looks the way it does.