Rules — what is allowed to exist

Rules are not created by software.

They exist because someone has decided that some situations are acceptable — and others are not. Systems can enforce rules, but they do not invent them.

Rules do not cause things to happen.
They do not trigger processes.
They do not move data.

Rules judge whether a situation is allowed to exist.

Situations exist before rules judge them

At any moment, a business is in a particular situation.

An order exists.
A payment was made.
An invoice is unpaid.
Information is visible to someone.

Systems record these situations as they are — even when they are undesirable or incorrect. The mere existence of a situation does not make it acceptable.

That distinction is critical.

Rules define acceptance, not behavior

Rules do not explain how a situation came to be.
They do not explain what should happen next.

They answer one question only:

Is this situation allowed?

If the answer is no, the situation is invalid — even if the system could technically continue.

Shared language matters

Rules are written using the everyday language of the business.

Customers, orders, invoices, balances, approvals, access.

If people do not agree on what these things are, rules involving them will always feel inconsistent. Clarity starts with shared understanding — not enforcement.

A simple test

If you are unsure whether something is a rule, imagine this:

The situation happened.
No one noticed.
Nothing broke immediately.

Later, it is discovered.

If you would still say this should never have been allowed, you are dealing with a rule.

If not, the issue lies elsewhere.

Stable boundaries create trust

When rules are clear and stable, systems prevent invalid situations instead of correcting them later.

When rules are vague or externalized, control shifts to people. Manual checks replace structure. Exceptions become routine.

Rules do not make systems complex.
Unclear rules do.