Business Rules

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 and configure the data model, classifications, and rules. In day-to-day operation, regular users work entirely within these definitions.

Administrators are technically subject to the same read and write rules as other users, but because they can modify system configuration, they can always change or disable rules if needed. The administrator role is therefore intended for system setup, configuration, and maintenance—not for routine operational 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 context-specific logic depending on how data is accessed.

The only exception is GDPR personal-data export, where authorized users may export a predefined data scope regardless of read rules, as required by regulation. All such accesses are fully logged, making it possible to see exactly which employee viewed which personal data and when.

Outside of this explicitly governed flow, read rules are enforced uniformly everywhere.

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.

They are attached to classifications and evaluated in real time whenever an action is attempted. Write rules are enforced consistently across all entry points, including:

• forms and inline editing
• bulk operations
• APIs

When a rule blocks or affects an action, the user is informed directly in the interface. Forms clearly indicate why an operation is not allowed or requires confirmation, rather than failing silently or allowing inconsistent states.

Rules can also be scoped by role. The same underlying classification logic may apply differently depending on the user’s role—allowing, restricting, or blocking actions for specific groups without duplicating rules.

This ensures that business constraints are enforced at the point of action, explained to the user when they matter, and applied uniformly regardless of how data is modified.

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.

→ Read more: Rules and permissions