Classifications as first-class system logic
In Minyu, classifications are the primary way meaning is expressed in the system. Instead of embedding conditions in code, queries, or UI logic, Minyu uses declarative classifications to define when something is true about a row.
A classification always evaluates to true or false for each row in a table and is kept continuously up to date as data, relationships, or time change. These evaluations form a shared foundation for access control, validation, filtering, search, scheduling, automation, and rules.
Classifications are not a secondary feature used by other parts of the system. They are the layer that turns structure into behavior.

Why classifications exist
In most business systems, the same condition is implemented repeatedly:
- in UI validation
- in backend logic
- in reports and dashboards
- in integrations and exports
Over time, these copies drift. Small differences appear, assumptions are made locally, and eventually different parts of the organization operate on different interpretations of what should be the same concept.
Minyu avoids this by expressing conditions once, as classifications, and reusing them everywhere.
A classification that determines whether a row is valid, active, eligible, or restricted means the same thing regardless of where it is used. The system does not reinterpret conditions based on context—the classification result is authoritative.
This keeps logic centralized, inspectable, and stable over time.
Classifications as shared organizational language
Many of the most important concepts in an organization are informal and unstable. Terms like “gold member”, “active customer”, “approved supplier”, or “ready for invoicing” are often understood differently by sales, finance, operations, and support.
Minyu forces these concepts to be made explicit.
A classification defines exactly what a concept means, in terms of data, relationships, and conditions. Once defined, that meaning is reused everywhere: in lists, access rules, rules, charts, filters, exports, and integrations.
Example
A “Gold member” classification might be defined using a combination of:
- minimum account age
- total lifetime spend
- presence of at least one active contract
- absence of overdue invoices
Once defined, this classification becomes the single source of truth.
Sales filters, finance reports, access rules, APIs, and automation all refer to the same definition.
Instead of debating interpretations across teams, the organization debates and evolves the classification itself. When the definition changes, the impact is visible immediately across the system.
Over time, classifications become a shared, executable vocabulary. Business concepts stop being conventions and start being clearly named definitions with system-wide consequences.
Three types of classifications
Minyu supports three classification types, each addressing a different category of logic. Together, they cover most real-world conditions found in operational systems.
Value classifications
Value classifications evaluate a single column in a table using a predicate.
They are used for conditions that depend only on the content of a field.
Examples
- “Email is present”
- “Email has a valid format”
- “Age is greater than 18”
- “Registration date is before today”
Value classifications are continuously re-evaluated. If the underlying value changes—or if time itself affects the outcome—the classification updates automatically. No manual refresh or recomputation is required.
Because value classifications are boolean and explicit, they can be reused safely across validation, filtering, rules, and access logic.

Relational classifications
Relational classifications evaluate a row based on its relationships to other rows, rather than only its own fields.
They follow declared relations across the data model, collect a distinct set of related rows, and evaluate that set against a condition.
Examples
- “A person has at least one active contract”
- “A booking has no overlapping bookings”
- “An order contains at least one approved item”
Relational classifications are fully declarative. They define: * which relations may be followed * how related rows are filtered * what condition must hold for the result
Minyu evaluates these classifications automatically whenever related data changes. Depth and result size are bounded to ensure predictable performance.
This allows relationship-dependent logic to be treated as part of the domain model, rather than buried inside queries or application code.

Logical classifications
Logical classifications combine existing classifications using boolean logic.
They are used when a condition depends on several independent requirements, possibly coming from different tables or different classification types.
Examples
- “A person is eligible if age is valid and identity is verified”
- “A customer is contactable if any contact method is available”
- “An entity passes validation if one of several criteria is met”
Logical classifications reference existing classifications and define which combinations of outcomes should evaluate to true. Conceptually, this behaves like a simplified truth table: only accepted combinations are listed; everything else evaluates to false.
Logical classifications can reference other logical classifications, allowing complex conditions to be assembled from smaller, well-named building blocks instead of monolithic expressions.

The foundation for rules and behavior
Rules in Minyu are built on top of classifications.
Because classifications are boolean, deterministic, continuously evaluated, and globally available, they provide a reliable substrate for expressing behavior without duplication. Access control, validation, scheduling constraints, automation, events, search, charts, and integrations all consume the same classification outcomes.
This guarantees that a condition means the same thing everywhere it is applied.
Long-term effects
Systems built around classifications tend to remain understandable over time.
Conditions are named. Relationships are explicit. Side effects are visible.
Instead of asking “Where is this logic implemented?”, users can ask “Which classifications define this behavior?” — and get a clear, inspectable answer.
In Minyu, classifications are not an auxiliary feature. They are how meaning is defined, shared, and enforced across the system.