How to write down your decision rules in plain language

A decision rule is a sentence that says what you do in a specific situation and why. Every knowledge professional uses them: a consultant knows when a project is not right for them, a trainer knows when to switch exercises, an adviser knows which question to ask before giving a figure. Most of those rules are not written down anywhere; they live in the head of whoever applies them.

Writing them down does two things. The first is for you: putting a rule into words shows whether you really always apply it, what its exceptions are and whether you still agree with it. The second is for whoever works with you, whether a colleague or your digital twin: a written rule can be passed on, reviewed and improved; a hunch cannot.

Because a rule only its author understands cannot be reviewed. And a rule that cannot be reviewed is no use for delegating.

ISO 24495-1, published in 2023, sets out governing principles and guidelines for writing plain language documents and states that they also apply to technical writing. A decision rule is a very short technical text, so the standard is the same: whoever reads it should understand it first time and know what to do with it.

In practice, plain language means short sentences, one idea per sentence, explicit conditions and words you would use talking to a client. If a rule needs a glossary to make sense, rewrite it.

A good rule answers four questions: when it applies, what you do, why, and where it comes from.

With those four parts, the rule can be checked: find a real case and see whether the condition was met and the action applied.

They are easier to write starting from cases than from principles. This six-step method works for almost any profession.

• 1. Pick one area: proposals, first meetings, project follow-up, choosing clients. Just one to start.
• 2. Recall five real cases in that area, the ones that went best and the ones that went worst.
• 3. Ask what you decided in each case and why. Write it as you would tell a colleague.
• 4. Look for what repeats. If you did the same thing for the same reason in three cases, there is a rule.
• 5. Write it with the four parts: condition, action, why and source.
• 6. Test it against a new case. If the rule would not have told you what to do, it is missing a condition or has an exception worth writing down.

A good rhythm is to write a few rules at a time and review them a few days later with fresh eyes. Rules written in one sitting tend to be too general.

The difference is almost always in the condition. A bad rule says what you value; a good rule says what you do.

A quick way to spot a bad rule: if nobody could disagree with it, it probably says nothing.

Write them as rules of their own or as part of the condition. A rule with unwritten exceptions is a trap: whoever applies it will follow it in exactly the case where you would not have.

For example, if your rule is "no quote without meeting the decision-maker", but you make an exception for clients who have hired you before, the rule becomes: "If the client is new and I have not met the decision-maker, I send no quote. For clients who have hired me before, I send it and ask for the meeting afterwards."

It is also worth marking how solid each rule is. A rule you have applied for years has high confidence; one you have drawn from two cases is a hypothesis with low confidence, and the honest thing is to say so.

By reviewing them when something changes: a case that contradicts them, a shift in your market, a new view. ISO 30401, which sets requirements for knowledge management systems, speaks of establishing, maintaining, reviewing and improving; the same sequence works for a set of rules.

The practical approach is to work in versions. You correct the rules in a draft and, when it is ready, put it into force with a note explaining what changes and why. That way you always know which criteria applied at any point.

In Digital Twin by Legathum, these rules make up the Book of Criteria, the layer of each twin's brain that holds your decision rules, in plain language, reviewed and approved by you, each with its source. Rules can arrive as candidates from your documents and sessions, but none counts until a person reviews it.

Writing good rules is what makes a twin worth having. Anyone can copy a face; copying someone's judgement is the hard part.

• Today: each twin's Book of Criteria, with rules that enter for review, are approved by version and export as Markdown or YAML.
• In development: the twin applying your rules in conversation and saying which rule each answer comes from.