The Rules layer sets the limits. One rule carries most of the weight: when information is missing, say so and stop, never fill the gap. Everything else is trade-specific. This is the layer that decides whether a workflow is safe to put in front of a customer.
Key takeaways
- Write the missing-information rule first. It is the most valuable line in the whole Stack.
- Rules are learned from failures. Every bad output gives you one more rule.
- Regulated work needs an escalation rule before it needs an answering rule.
- Test rules by deliberately breaking the input and confirming the flag appears.
- Rules are short imperatives, not a policy document.
The rules every business needs
| Rule | Why |
|---|---|
| Flag missing information at the top, never assume it | Gap filling looks correct, which makes it the dangerous failure |
| Use only the supplied figures and prices | Stops invented numbers reaching a customer |
| Never promise a date, a timeline or an outcome | Those are commercial commitments, not drafting decisions |
| Keep GST separate and state it | Arithmetic errors in tax are expensive and obvious |
| Limit the scope to our listed services | Assistants pad scope with plausible extras |
| Use our terms, not synonyms | Renaming a service mid-document confuses customers |
Trade-specific rules
Trades and construction. Never estimate a measurement. Do not specify a repair method. Do not comment on compliance or certification.
Health and allied health. Never give health advice. Never comment on symptoms, conditions or medications. Escalate anything clinical to the practitioner. See the health practice example.
Professional services. Do not state a legal, tax or financial position. Draft from the file and mark anything requiring professional judgement.
Anything customer-facing. Nothing sends without a human reading it.
Write the escalation rule first
In regulated work the most valuable behaviour is refusal. A workflow that cannot answer a clinical or legal question cannot answer it wrongly. Write what it must escalate before you write what it may answer, and the rest of the Stack becomes much easier to trust.
How to test a rule
Break the input on purpose. Remove a measurement from the site notes and run it. If a quote comes back with a number in that line, the rule is not strong enough. Tighten it and rerun the same example.
Do this once per rule when you build the Stack. It takes a few minutes and it is the difference between believing the workflow is safe and knowing it.
Rules come from failures
The first version of your Rules layer will be short. It grows every time something comes back wrong, because each wrong output names a missing limit. Keep a running list of what broke and what fixed it, and that list becomes the most valuable page in the system.
Where it sits in the Stack
Rules is layer four, between Source and Output. Read the full Context Stack.
Build and test yours on a real job: a full day at Avani Mooloolaba Beach Hotel, A$495 excluding GST, capped at 15 people. See the workshop, or enquire about onsite team training.
Frequently asked questions
What is the most important rule?
Flag missing information instead of filling it. Gap filling produces output that looks right and is wrong, which is the failure most likely to reach a customer.
How many rules should a Stack have?
Start with four or five. Most mature Stacks settle around eight to twelve. Beyond that they usually need splitting into two Stacks.
How do you stop AI giving advice it should not give?
An explicit escalation rule naming the categories it must refuse, tested by asking it one of those questions and confirming it escalates. See how we check output.
Do rules replace human review?
No. Rules reduce how often review catches something. A person still reads anything going to a customer. Human approval in workflows.
Why did it ignore a rule?
Usually because the rule was a preference rather than an instruction. "Try to keep it short" is a preference. "Maximum four paragraphs" is a rule.
Should rules be in the same place as the prompt?
Keep them written in the Stack so every run uses the same set. Typing them from memory each time is how variation returns. Maintaining workflows.