Rules live outside the system

Summary

In many small and medium-sized businesses, important rules are not implemented inside the system.

They live in:

• People’s heads
• Email instructions
• Slack messages
• Checklists
• “How we usually do it”

The system stores data.
But the rules that decide what is allowed often exist elsewhere.

This creates a structural gap between what the system permits and what the business actually considers correct.

Touches lenses:
Rules, Interaction, Processing

A simple example

Imagine a company where sales staff create orders in a system.

There is an important rule:

Orders above 50,000 must be approved by a manager.

But the system does not enforce this rule.

Instead:

• Sales reps are told during onboarding.
• Managers are expected to “keep an eye on it.”
• Finance double-checks large invoices manually.

The rule exists.
But it does not exist inside the system.

If someone forgets, the system will not stop them.

The rule lives outside.

Recognition

You may have rules living outside the system if:

• People say, “Make sure you remember to…”
• Work requires manual review before it is considered valid
• A spreadsheet exists to “double-check” system data
• Errors are caught by people, not by constraints
• New employees make mistakes that “everyone else knows not to make”

The system is technically working.

But correctness depends on memory and discipline.

What is really happening

A business rule defines what is allowed to exist.

For example:

• A discount may not exceed 20%.
• A contract must have a start date before an end date.
• A booking cannot overlap with another booking.
• A customer must have valid tax information before invoicing.

If these conditions are not encoded as constraints, validations, or state transitions inside the system, then the system allows situations the business considers invalid.

The rule becomes advisory instead of structural.

The system becomes a recording tool, not a governing structure.

Why this happens

There are several common reasons.

1. The system was added later

The business existed before the software.

Rules were already enforced through habits and supervision.

When software was introduced, it focused on storing data — not fully modeling constraints.

2. The rule feels “too complex”

Some rules depend on combinations of:

• Customer type
• Contract status
• Time period
• Region
• Internal approval level

Instead of modeling this complexity, teams rely on manual checks.

3. “We’ll fix it in process”

Sometimes the belief is:

“It’s fine. Finance will catch it.”
“Operations always reviews that.”

Over time, these human checkpoints become permanent parts of the workflow.

4. Fear of rigidity

There is often concern that strict rules will slow people down.

So the system is left flexible — and correctness is handled socially.

Why it is hard to see

Unlike semantic problems, this issue rarely shows up as conflicting numbers.

Instead:

• Data looks correct most of the time.
• Errors are rare but expensive.
• Work feels heavy because of repeated checking.

Because people compensate for the system, the system appears to function.

The hidden cost is ongoing human effort.

The more disciplined the team is, the less visible the structural weakness becomes.

A second example: invoice approval

A company has a rule:

All supplier invoices above 10,000 must have two approvals.

But the accounting system allows invoices to be marked as “approved” by anyone.

The real process becomes:

1. Invoice is entered.
2. Accountant emails two managers.
3. After confirmation, the accountant manually updates the status.

If the accountant forgets step 2, the system will not object.

The rule depends on behavior, not structure.

When staff change, errors increase.

When workload rises, approvals are skipped.

What it costs

When rules live outside the system:

• Training becomes critical and fragile.
• Knowledge transfer becomes risky.
• Audits become stressful.
• Scaling increases error probability.
• Automation becomes dangerous.

Automation assumes rules are inside the structure.

If rules only exist socially, automation amplifies mistakes instead of preventing them.

There is also a trust problem.

Leadership believes:

“The system ensures this.”

But in reality, the system does not.

People do.

Structural diagnosis

To diagnose this pattern, ask:

1. If a new employee with no training used the system strictly as designed, what invalid situations could be created?
2. Which corrections happen after the fact?
3. Which reports require manual filtering before presentation?
4. Which errors are usually described as “someone forgot”?

Another strong diagnostic question:

If all employees followed only what the system technically allows, would the business still operate correctly?

If the answer is no, rules live outside the system.

Why SMBs are especially exposed

Small and medium-sized businesses often rely on:

• Close communication
• Experienced staff
• Informal escalation
• Direct supervision

This works well at small scale.

But when:

• The team grows
• Locations multiply
• Remote work increases
• Staff turnover rises

Informal rule enforcement becomes unstable.

What worked with 5 people becomes fragile with 25.

Structural resolution

The goal is not to encode every minor preference.

The goal is to encode structural correctness.

A practical approach:

1. Identify high-risk rules

Start with rules that:

• Protect money
• Protect compliance
• Protect customer trust
• Prevent irreversible errors

These should not depend on memory.

2. Distinguish validation from process

Some rules should block creation of invalid data.

Others should control state transitions.

For example:

• A discount limit may be a field constraint.
• A large order may require a status change only possible after approval.
• An overlapping booking may be prevented through a time conflict rule.

3. Make invalid states impossible

Instead of telling people not to do something, model the system so it cannot happen.

When invalid states are impossible, enforcement disappears as a manual burden.

4. Keep flexibility explicit

If exceptions are needed, model them explicitly:

• Add an override flag.
• Require justification.
• Log the decision.

Flexibility should be structured, not invisible.

A short FAQ

Why do we still need people if rules are in the system?

People handle judgment and interpretation.
The system handles structural boundaries.

Won’t strict rules slow us down?

In the short term, possibly.
In the long term, they reduce rework, audit effort, and confusion.

Is this about compliance only?

No. It affects revenue leakage, margin control, and operational stability as well.

In short

Rules define what is allowed to exist.

If they are not inside the system, they are only suggestions.

When correctness depends on memory, supervision, or habit, the system is not governing the business — it is only recording it.

As the business grows, this gap becomes increasingly expensive.

Bringing rules inside the structure turns discipline into design.