Declarative business rules and access control

In Minyu, business rules and access control are expressed declaratively and enforced uniformly across the system. Instead of scattering conditions across UI logic, backend code, and integrations, rules are defined once and applied everywhere the same way.

Rules answer questions such as:

• who may see a row
• who may modify it
• under what conditions an operation is allowed
• how the system should react when a rule is violated

All rules in Minyu are built on classifications. This ensures that decisions are based on explicit, inspectable conditions rather than implicit logic.

One rule engine for the entire system

Minyu separates system configuration from operational enforcement.

Administrators design the model, classifications, and rules. Once the system is live, operational users work entirely within those definitions. Administrators are not subject to read or write rules and therefore always have full access. This role is intended for configuration and commissioning, not daily use.

In production setups, administrator rights should be limited to one or more trusted system accounts. All operational access is then governed strictly by rules.

This separation ensures that structure and enforcement remain stable and predictable over time.

Read rules: controlling visibility

Read rules determine which rows a user is allowed to see.

They are attached to classifications and evaluated continuously. A rule does not grant partial visibility — a row is either visible or hidden. This applies consistently across:

• lists and views
• search
• charts
• exports
• APIs

There is no special case logic depending on where data is accessed.

Example

A “Sensitive customer” classification evaluates to true when a customer is flagged for special handling.

A read rule denies access when this classification is true.

The result:
- the customer does not appear in lists  
- cannot be found via search  
- is excluded from exports  
- is invisible to the API  

No additional logic is required elsewhere.

Optimistic and pessimistic access models

Minyu allows the organization to choose a global visibility strategy.

• Optimistic: rows are visible unless explicitly denied
• Pessimistic: rows are hidden unless explicitly allowed

This choice defines the system’s security posture and applies everywhere. Regardless of policy, deny always takes precedence. If both allow and deny conditions apply, the row is hidden.

This guarantees predictable and security-safe behavior even in complex rule setups.

Write rules: controlling actions

Write rules determine whether a user may create, modify, or delete data.

Write rules are also attached to classifications and are evaluated in real time whenever a user attempts an operation. They apply uniformly across:

• smart forms
• inline editing
• bulk imports
• APIs

Write rules do not silently fail. They provide explicit feedback explaining why an action is blocked or requires confirmation.

Example

A “Booking is locked” classification evaluates to true once a booking has started.

A write rule blocks edits when this classification is true.

The result:
- users can still view the booking  
- historical data remains accessible  
- edits that would violate the rule are blocked with a clear explanation  

Importantly, write rules only block new violations introduced by the current change. Existing issues are visible but do not prevent unrelated updates, avoiding unnecessary deadlocks in daily work.

Rule severity and user feedback

Write rules support different severity levels:

• Error – blocks the operation
• Warning – allows saving with notice
• Information – informational only
• Confirmation – requires explicit user acknowledgment

This allows rules to express intent precisely: some conditions must never be violated, while others merely require awareness or confirmation.

Role-aware rule scoping

All read and write rules can be scoped by role.

A rule may:

• apply only to selected roles
• apply to all roles except selected ones
• apply globally

This allows the same classification logic to be reused while enforcing different behavior for different user groups.

Example

The same “Financially restricted” classification can:

- deny visibility to regular users  
- remain visible to finance roles  
- block edits for all except administrators  

The logic is shared; enforcement adapts by role.

Built on classifications, enforced everywhere

Because all rules consume classification outcomes:

• conditions are evaluated once
• logic is not duplicated
• behavior remains consistent

Rules do not introduce new logic — they operationalize existing meaning.

When a classification definition changes, the effect propagates immediately across the system: UI behavior, API behavior, search results, exports, automation, and integrations all update together.

Why this approach matters

Rule systems tend to become brittle over time. Small exceptions accumulate, logic gets duplicated, and behavior becomes context-dependent.

Minyu avoids this by:

• expressing conditions declaratively
• separating meaning from enforcement
• applying rules uniformly everywhere

Instead of asking “Where is this checked?”, users can ask “Which classification controls this?” — and get a clear answer.

In Minyu, business rules are not hidden implementation details. They are explicit, shared, and derived directly from the system’s understanding of the domain.