From team conversation to system criterion: writing rules down before automating

The criterion lives in someone's head

Take a rule that currently lives only in team conversations, messages and the memory of a coordinator, and turn it into a written criterion a system can apply. By the end, you will have the rule broken into explicit "if, then, else" routes, an observable source, written exceptions, and a defined path for the cases the criterion does not settle on its own.

This step is the prerequisite that checking and approval flows tend to assume is done. Every audit that compares a charge against a contracted rate assumes the rate exists in a readable version. Every exception queue assumes the triage criterion is written down. When it is not, the automation receives a rule that only exists in someone's head and reproduces the team's guessing at a larger scale.

The example threading this post is hypothetical. Consider a receiving operation where the vehicle's dwell window at the dock is two hours, a number taken as the scenario's premise. The rule works in practice: the coordinator looks at the arrival time, the unloading start time and the queue for the day, and decides whether the carrier's detention charge is justified. Nobody wrote that down. When the coordinator goes on vacation, the decision depends on who remembers what, and when an automated flow tries to apply the rule, the rule simply does not exist for it.

Pick the rule that stalls the most work

Start from the blocker, not the easiest rule to write. The natural source is the exception queue that already exists: the discrepancies that go back to human review in invoice and document checking, the charges disputed with suppliers, the approvals that wait on one specific person.

Pass condition for this step: the rule chosen has records of recent blockers, in the queue, in email or in the team's chat. Fail condition: nobody can say how often it stalls the process in a month.

There is a conscious trade-off here: covering every rule in the operation before automating anything is a path that often never ends. We pick the opposite side. Write the few rules that stall the most first, run the flow only on those, and leave the rest in conversation for now.

Write each route in if, then, else form

A discussed rule does not become a criterion simply by writing it as prose. It becomes one when it separates the situations the system will encounter and states what happens in each. In the hypothetical example, three routes:

If the interval between the recorded arrival and the start of unloading stays within two hours, there is no overage to assess and the flow moves on. If the overage exists and more than half the docks were occupied at arrival, the delay plausibly came from outside the carrier. The criterion then checks the contract before deciding: when the contract provides for the charge under those conditions, it goes for approval before the financial obligation is created or payment is released, depending on when the client's ERP creates one or the other; when the contract does not provide for it, the charge goes to review. If data or the contract is missing, the charge also goes to review. If the overage exists and half or fewer of the docks were occupied, the delay may be the carrier's own doing, and the criterion neither approves nor rejects on its own: the charge enters the review queue with the reason and the evidence, and whoever decides checks the contract before concluding.

Note that the discussed rule covered only the number. The "two hours" was in everyone's head; what distinguished the situations, in the coordinator's judgment, was dock occupancy, defined here as a premise of this example. Writing the rule down is how you surface those conditions.

The step is done when every route has a written destination and a person who never joined the conversation can apply it. It is not done while the text depends on judgment without a defined condition, such as "excessive wait" with no number, or "when it makes sense".

Tie every condition to observable evidence

A criterion nobody can verify afterwards is not a criterion, it is formalized opinion. Each condition points to a source that exists independently of who applies it: the timestamp on the arrival record, the occupancy logged in the system, the dated version of the contract, the field on the document. This is the same principle as in freight invoice auditing: the audit survives when it compares against neutral evidence, not against memory.

This is where the project's real limits show up. The example rule only becomes an applicable criterion if the arrival time and dock occupancy are logged in some system. If they are not, the work changes: first the record has to exist, then the rule applies. Skipping that step makes the flow decide with no source, and the result is harder to defend than the manual decision it replaced.

Write the exceptions alongside, not after

Every rule has the cases it does not cover, and they are easier to list while the rule is fresh in the conversation than months later, when someone meets a case with no answer. In the example: unloading interrupted by damage, arrival outside the scheduled window, delay caused by the carrier itself.

Each exception needs a destination, and this is where the design connects with what we described in human review and automation limits: for each exception, who decides and with what information at hand. The exception with no defined destination is the one that usually becomes the flow's real blocker after deployment.

Validate against history before switching on

Before any automation, apply the written criterion to the last decisions the team made from memory. Take the recent dwell cases, apply the example rule, and compare with what the coordinator decided at the time. When the criterion reproduces past decisions, that is a good sign, but not enough: past decisions may disagree with the contract or with current practice, so each one gets checked before it becomes a reference. When it disagrees with some of them, or the team adjusted the criterion case by case, the text needs fixing, and it is better to find out before the system decides.

This step is also an honest conversation with the team: they see their own judgment being written down and fix the text while fixing it is still cheap. After that, the rule is ready for the validation criteria of a pilot, if the flow goes through one.

flowchart TD
  A[Rule living in team conversation] --> B[Pick the rule that stalls the most]
  B --> C[Write the routes: if, then, else]
  C --> D{Does every condition have observable evidence?}
  D -- no --> E[Record the source: timestamp, field, dated version]
  E --> C
  D -- yes --> F[Write exceptions with a defined destination]
  F --> G[Apply the criterion to recent history]
  G --> H{Does the criterion reproduce past decisions?}
  H -- no --> C
  H -- yes --> J{Decisions checked against contract and current practice?}
  J -- no --> C
  J -- yes --> I[Ready to enter the flow]

In summary

Checklist for every rule before it becomes a system criterion:

• The rule was chosen for how often it stalls the work, not for how easy it is to write.
• It separates the day-to-day situations and routes each one to a written destination: flow moves on, approval or review.
• Every condition points to observable evidence, with source and date.
• The exceptions are written down, and each one has an owner deciding.
• Uncertain cases go to review, and no charge becomes a financial obligation without the required approval.
• The criterion reproduced the team's recent decisions, and each reproduced decision was checked against the contract and current practice.

A rule that passes this list stops depending on one person's memory. One that does not is still in conversation, and automation over conversation reproduces guessing at a larger scale.

Want to assess which rules in your operation are ready to become criteria? Request a diagnostic.