Document business rules for AI apps in plain language

Why unclear rules create unreliable apps

Business rules tell an app what to do in real situations. They answer questions like who can approve a request, how a total is calculated, and what happens when a case falls outside the usual pattern.

If those rules are vague, the app still has to choose a path. It just might not choose the one you expected.

Take a rule like "large expenses need manager approval." A person might think that sounds clear. A builder does not. What counts as large: $500, $5,000, or anything above a team budget? Which manager: the direct manager, the department head, or finance? If no one replies in two days, does the request wait, expire, or move to someone else?

That is why vague rules lead to unreliable apps. The builder can only be as consistent as the instructions it receives. When the wording leaves room for guesswork, the app may behave one way today and another way tomorrow when a slightly different case appears.

The biggest problems usually show up in a few areas:

• calculations with missing details, such as rounding, tax, discounts, or date ranges
• exceptions that everyone assumes but nobody writes down
• approval steps with no clear owner, order, or fallback

A simple example shows the problem. A founder builds an internal expense app in Koder.ai and writes, "Reimburse travel costs unless they seem unusual." That sounds reasonable, but the app has no reliable way to judge unusual. One employee's taxi gets approved, another similar one gets flagged, and nobody knows why.

Reliable behavior starts with rules that can be followed the same way every time. Words like "large," "urgent," and "special case" need to be replaced with exact limits, conditions, and actions. If two different people would apply the rule the same way, the app is far more likely to do the same.

What a clear business rule looks like

A clear business rule covers one decision or one action, not an entire process. This matters more than most teams expect. When one rule tries to cover approval, pricing, exceptions, and notifications at once, the builder has to guess which part matters most.

A good rule is easy to read out loud. Someone outside your team should understand it without needing your internal shorthand. Replace terms like "fast-track," "standard case," or "manager sign-off" with plain language that says exactly what happens.

Most clear rules answer four basic questions:

• Who makes the decision or takes the action?
• When does the rule apply?
• What changes in the app?
• What happens next?

That structure keeps the rule tied to real behavior. Instead of writing, "Large orders need review," write, "If an order is over $5,000, the sales manager must approve it before it can be sent to fulfillment." One sentence, one decision, one result.

It also helps to keep related rules separate. The approval rule should stand on its own. The rule for sending an email should be separate. The rule for blocking shipment should be separate too. That makes each rule easier to test, update, and fix.

The difference is easy to see:

"Premium customers get priority handling" is vague.

"If the customer has a premium plan, the support request is marked High Priority when the ticket is created" is clear.

The second version names the trigger, the condition, and the change inside the app. It tells the builder what reliable behavior should look like.

If you are using a chat-based builder, this kind of wording makes a big difference. Clear rules do not need legal language. They need simple words, one idea at a time, and an expected result that fits in a single sentence.

Writing calculations in plain language

Calculations often look simple until someone tries to build them. The safest approach is to start with one plain sentence that says exactly what the app must do.

A good rule sounds like this: "The reimbursement amount equals approved miles multiplied by the mileage rate." That is much clearer than "calculate travel pay" or "apply standard reimbursement."

After that first sentence, define every input the app should use. Be specific enough that the builder does not have to guess.

What to define for every calculation

For each calculation, spell out:

• the inputs, with simple names and units
• where each value comes from
• rounding rules
• any minimum or maximum value
• what happens if a value is missing

Small details matter. "Round the final amount to 2 decimal places" gives a different result than rounding each line item first. If there is a cap, say whether the app should stop at that cap or show a warning.

A rule written in plain language might look like this: "The travel reimbursement equals approved miles x $0.67. Round the final amount to 2 decimal places. The maximum reimbursement is $300 per trip. If approved miles is blank, do not calculate the amount. Mark the request as incomplete and ask the user to enter miles."

Then add one or two worked examples with real numbers. Examples expose gaps faster than abstract formulas.

Example 1: "If approved miles is 120, reimbursement is 120 x $0.67 = $80.40. Because this is below the $300 cap, the final amount is $80.40."

Example 2: "If approved miles is 500, reimbursement is 500 x $0.67 = $335.00. Because the maximum is $300, the final amount is $300.00."

This style is easier for people to review and easier for a builder to turn into app behavior.

Capturing exceptions without confusion

Most apps do not fail on the main rule. They fail on edge cases.

The normal path might be simple, but real work includes refunds after a deadline, VIP customers, missing documents, and one-off approvals. If exceptions are left out, the app fills in the gap on its own, and that is where inconsistent results begin.

A simple way to write exceptions is to use short if-then rules. Keep each one focused on one condition and one outcome.

• If the expense is under $100, then auto-approve.
• If the expense is under $100 but submitted after 30 days, then send it for manual review.
• If the employee is in the executive team, then skip the $100 limit and route to finance.
• If a finance admin marks the claim as urgent, then manual override applies and the claim moves to the top of the queue.

This format makes hidden logic visible. It also helps you spot overlaps before they turn into bugs.

Just as important, say which rule wins when two rules clash. A customer might qualify for a discount, but the order may also fall into a holiday blackout period. Write the priority in plain language: "If a holiday blackout rule conflicts with a customer discount rule, the blackout rule wins."

Be exact about limits. Dates, user types, locations, account status, and manual overrides often change the outcome. Instead of writing "late submissions need approval," write "If a request is submitted more than 14 calendar days after the event, then manager approval is required."

Also say what the app should show the user in each exception. A good rule does not stop at the decision. It also defines the message, such as "Submitted after 14 days. Manager approval required" or "Manual override applied by finance admin."

When exceptions are written this way, unusual cases stop feeling unusual. They become normal, testable behavior.

Describing approval logic step by step

Approval logic works best when it is written as a sequence of decisions, not as a vague policy. Each step should answer five questions: who acts, what triggers their review, what limits apply, how long they have, and what status the request gets after they decide.

Start by naming the role, not just the team. Instead of writing "finance reviews large requests," write "the Finance Manager can approve, reject, or send back any request over $5,000." That removes guesswork and makes the behavior easier to build.

Then define the trigger for each step. A trigger is the condition that sends the request to the next person. It can be based on amount, department, risk level, request type, or a mix of these.

For example:

• If the request is under $500, the team lead reviews it.
• If the request is $500 to $5,000, the department manager reviews it after the team lead approves.
• If the request is above $5,000, finance reviews it after the department manager approves.
• If the request is marked high risk, compliance must review it before final approval.

Thresholds need exact boundaries. Do not say "large" or "sensitive." Say "above $5,000," "from the Sales department," or "risk score 8 or higher." If two thresholds can apply at the same time, say which one wins. For example: "High risk always goes to compliance, even if the amount is low."

You also need a timeout rule. If nobody responds, the app should not sit in limbo forever. Say what happens after a set time, such as 48 hours or 3 business days. The request might be escalated to the approver's manager, reassigned to a backup approver, or automatically canceled.

Finally, define the status after every decision. Keep the labels short and consistent:

• Approved: the request moves forward or is completed.
• Rejected: the request closes and no further action is taken.
• Sent back: the requester must edit and resubmit.
• Escalated: the request moves to a backup or higher approver.

When approval logic is written this way, the builder has less room to guess and the workflow becomes much more reliable.

A simple rule template you can reuse

If you want consistent behavior, give every rule the same shape. Mixed writing styles often create mixed results.

A simple format works well for most cases: trigger, conditions, action, result. It is short enough to write quickly and clear enough for someone else to review later.

Use one rule, one unit

Keep each rule on its own line, card, or block. Do not pack several ideas into one paragraph. If a rule covers pricing, approval, and an exception at the same time, it becomes hard to test and easy to misread.

A practical template looks like this:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

You do not need every field every time. But keeping the same order helps people scan rules quickly.

For example:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

Notice that the example sits under the rule, not inside it. That keeps the rule clean. The example only proves how the rule should behave.

Mark assumptions clearly instead of hiding them in the sentence. A small note like "Assumption" or "Needs confirmation" makes open questions easy to review before build time.

It also helps to keep your wording consistent. Always start triggers with "When," conditions with "If," and actions with "Then." Small patterns like this reduce confusion, especially when rules are being turned into app logic.

A quick test works well here: can someone test this rule, and can someone misread it? If the answer to the first is no, or the second is yes, tighten the wording.

Example: an expense approval app

An employee expense app is a good test case because the policy is familiar and the edge cases show up quickly. Staff can claim meals, taxi rides, hotels, and small client costs, but each claim has limits, exceptions, and approval steps. This is exactly the kind of process where plain language matters.

Sample policy

Write the meal rule like this: employees can claim up to $40 per day for meals during normal workdays. The app should total all meal receipts for the same date and compare that total to the daily limit, not each receipt by itself.

If the employee spends $12 on breakfast and $22 on lunch on Tuesday, the total is $34, so the claim passes. If they add a $15 dinner on the same day, the total becomes $49, so the app should flag the claim as over the limit.

Now add an exception. If the meal happened during approved business travel or a client meeting, the daily meal limit increases to $75. That exception only applies when the employee selects either Travel day = Yes or Client meeting = Yes and adds a short note with the client name or trip purpose.

This is more reliable than vague wording like "special cases may be allowed" because the exception is tied to clear conditions.

Approval steps

The approval logic can stay just as plain:

• Claims under $100 are approved by the employee's manager.
• Claims from $100 to $500 need manager approval, then finance approval.
• Claims over $500 need manager approval, finance approval, and department head approval.
• Any claim marked "travel" also needs finance review, even if the amount is below $100.

You can test the rule with a few simple cases. A $36 meal claim on a normal workday should be approved if receipts are attached. A $60 meal claim on a travel day should pass if travel is marked and the note is filled in. A $60 meal claim on a normal day should be rejected or sent back for correction. A $650 hotel claim should move through all three approval steps.

That is the goal: the rule should produce the same result every time someone tests it with real cases.

Common mistakes that lead to bad results

A rule can sound clear to a person and still confuse a builder. That usually happens when the document is vague, packed with multiple ideas, or inconsistent from one line to the next.

One common mistake is cramming several rules into one long paragraph. For example: "Managers approve travel unless the total is high, finance checks receipts, and urgent requests can skip review." That may look efficient, but it hides several separate decisions. Split it into distinct rules so each action has one trigger and one outcome.

Another problem is fuzzy language. Words like normal, large, urgent, or recent only work if they are defined. If "large expense" means anything over $2,000, say that. If "urgent" means needed within 24 hours, write that exact condition.

Missing data is another major source of bad results. Teams often describe the happy path and forget to say what should happen when information is incomplete or wrong. If a request has no amount, no department, or no receipt, the rule should say what happens next.

The mistakes that cause the most trouble are usually these:

• combining multiple rules in one paragraph
• using undefined terms for size, time, or priority
• forgetting error cases and missing fields
• leaving final approval authority unclear
• changing names for the same thing halfway through

Final authority matters more than many teams expect. If a manager and a finance reviewer disagree, who makes the last call? If nobody owns the final step, the app may stall or send work in circles.

Term changes create quieter errors. If you start with "request" and later call it "submission" or "ticket," readers may assume those are different items. Pick one term and keep it throughout the document.

This matters even more in a chat-based builder, where plain language drives behavior. Clear rules do not need to sound formal. They need to be specific, consistent, and complete.

Quick checklist before you build

Before turning requirements into screens, flows, or prompts, do one last review. A short check now can save hours of fixing odd behavior later.

Make every rule testable. Each rule should end with a clear outcome such as yes or no, approve or reject, apply fee or do not apply fee. If two people could read the same sentence and give different answers, the rule needs work.

Spell out every calculation. Name the inputs, the formula, and when the calculation happens. Add rounding, currency, date handling, and what should happen if a value is missing or zero.

Keep exceptions separate. Write the default rule first, then add exceptions on their own. The main spending limit should not be buried inside a special case for contractors, urgent purchases, or pre-approved travel.

Map the full approval path. For each threshold, state who approves and what happens next. Be exact about edges too: say whether a rule starts above $500 or at $500 and above.

Then do the new-teammate test. Give the rule to someone who has not worked on it and ask them to explain it back in their own words. If they need extra context, the rule is still too vague.

A small example shows why this matters. "Manager approves large expenses" sounds clear until someone asks whether $500 counts as large. "Manager approves expenses above $500. Director approves expenses above $2,000. Expenses of $500 or less are auto-approved" leaves much less room for mistakes.

Turning rules into a working app

Once the rules are clear, review them with the people who use the process every day. Managers, coordinators, finance staff, and approvers often notice small details that never make it into the policy document. Those details are usually what make an app feel smooth or frustrating.

Treat the rule document as working instructions, not a one-time draft. It should explain what happens, who decides, what the exceptions are, and what the app should do when information is missing.

Before building the full app, test a few real scenarios from recent work. Use both clean cases and messy ones: a standard request that should pass, a request with missing information, an exception that needs manual review, and a case that crosses a spending limit or approval threshold.

This step catches gaps early. A rule may sound clear on paper but break down when a real request does not fit the expected pattern.

Once those scenarios hold up, move them into your builder. If you're using a chat-based platform like Koder.ai, a clear rule set makes the build much faster because you're translating a defined process into screens, actions, and approvals instead of making decisions on the fly.

After launch, keep the document as the source of truth. When a policy changes, a new approver is added, or a limit is updated, change the document first and then update the app. That keeps future edits simpler and lowers the chance of different people remembering the rule in different ways.

A small habit helps here: review the rules whenever the process changes, not only when the app breaks. Small updates made early are much easier than fixing confusing behavior later.

If the document stays current, the app becomes easier to test, improve, and trust over time.