Booking and scheduling

Scheduling in Minyu is not a separate calendar subsystem layered on top of the application. It is built from the same data model, classifications, and rules as the rest of the system. This allows availability, constraints, and dependencies to be evaluated together, so only valid booking options ever exist.

The goal is not to help users reason about time conflicts, but to remove the need for that reasoning entirely.

Scheduling based on structure, not guesswork

In many systems, booking works by allowing users to propose a time range and then rejecting it later if something conflicts. This pushes complexity onto the user and creates trial-and-error workflows.

Minyu inverts this model.

Time is treated as a structured resource. Instead of free-form input, the system evaluates all relevant constraints first and presents only time slots that are valid. If a slot is visible, it can be selected. If it would violate a rule, it never appears.

Constraints can include:

• existing bookings
• resource availability
• multi-resource dependencies
• role-based restrictions
• operational rules such as overlaps, gaps, or sequencing

From the user’s perspective, scheduling becomes a selection problem rather than a validation problem.

Reusable schedules as organizational building blocks

At the core of Minyu’s scheduling model is the idea that availability patterns should be defined once and reused.

Schedules represent repeating availability structures such as:

• working hours
• opening times
• shifts
• operational windows

These schedules are not bound to a single resource. The same schedule definition can be applied to people, rooms, equipment, or any other entity that participates in bookings.

Example

A single “Office hours” schedule defines weekday availability from 08:00–16:00.

That same schedule can be applied to:

- employees  
- meeting rooms  
- service counters  
- support functions  

Changes to the schedule propagate automatically everywhere it is used, ensuring consistency without duplication.

Multi-resource coordination without manual alignment

Bookings often involve more than one resource. A reservation may require a room, specific equipment, and a qualified person, all at the same time.

Minyu evaluates these dependencies together.

When a user attempts to create a booking, the system considers all involved resources and finds time slots where every required condition is satisfied simultaneously. Conflicts are resolved before the UI is rendered.

Example

A task requires:

- a machine  
- a licensed operator  
- a two-hour uninterrupted slot  

Minyu evaluates:

- the machine’s schedule  
- the operator’s work schedule  
- existing bookings  
- licensing classifications  

Only time slots that satisfy all conditions are presented.

This eliminates manual cross-checking and prevents hidden conflicts from entering the system.

Structural time rules vs. business rules

Minyu deliberately separates different kinds of constraints:

• Structural time rules define when time slots may exist at all
• Business rules and classifications determine whether a slot is valid in context

Structural rules enforce patterns such as office hours or shifts. Business rules enforce conditions such as overlap prevention, sequencing constraints, or role-based restrictions.

This separation keeps the system understandable and allows each layer to evolve independently without unintended side effects.

Only valid slots ever reach the user

Before any booking UI is shown, Minyu evaluates all candidate slots against relevant classifications and write rules. Invalid slots are removed entirely.

There is no disabled state, no warning after selection, and no late rejection.

Example

A rule prevents overlapping bookings.

When a slot would overlap an existing booking, it is never presented.

From the user’s perspective, the slot simply does not exist.

This creates calm, predictable workflows and dramatically reduces booking errors.

Scheduling that scales with complexity

Because scheduling is derived from declarative rules and reusable structures, complexity scales linearly rather than exponentially.

Adding a new constraint does not require rewriting booking logic. It means introducing or refining a classification or rule. The system incorporates it automatically into slot evaluation.

This makes Minyu suitable for both simple reservations and highly constrained operational planning — without changing how users interact with the system.

Why this approach matters

Scheduling problems often arise not from lack of flexibility, but from lack of structure. When time is treated as free-form input, every new constraint adds cognitive load.

Minyu avoids this by treating time as data that can be modeled, filtered, and validated like any other part of the system.

Users do not need to understand why a slot is valid. They only need to choose from the slots that are.

In Minyu, booking and scheduling are not special cases. They are a natural extension of the system’s core model of structure, rules, and meaning.