Single source of truth for rules that humans and AI follow

Why the same case gets argued twice

A team can look busy and still answer the same request three different ways. When rules live in chat threads, old docs, and one manager's memory, people fill the gaps with their own judgment. That works for a while. Then a customer, vendor, or employee gets a different answer than the last person did, and the debate starts again.

The pattern is familiar. One person follows the last case they remember. Another follows a spreadsheet or policy note that nobody updated. A manager approves an exception in chat, but the team never turns it into a rule. Then the AI assistant reads old tickets or loose notes and repeats the same mismatch.

When approval logic lives in people's heads and exceptions happen in chat, nobody can tell whether a choice was standard or a one-off. New hires guess. Experienced staff rely on memory. Any policy automation built on that mess just repeats it faster.

Edge cases make the problem louder. A late invoice, a discount just above the limit, or a contract change for a long-time customer can trigger ten messages in fifteen minutes. People ask who can approve it, what happened last time, and whether this case is "close enough" to the last one. Those pings feel small, but they add up and pull managers into routine decisions.

Without one trusted rule source, version control turns into a people problem. One person trusts the handbook. Another trusts the message a manager sent last month. The AI tool may trust whichever example appears most often in old conversations, even if that example was wrong. Before long, consistency starts to feel optional.

That is why the same case gets argued twice. The first argument is about the decision. The second is about which version of the rule counts. A shared decision table does not remove judgment, but it gives humans and AI the same starting point so the same case stops coming back in a new disguise.

What belongs in the shared table

A shared table works when each row covers one clear case. If a row mixes two ideas, people read it two ways, and AI will do the same. "Refund for damaged item under 30 days" is one case. "Refunds, exchanges, and special customer issues" is three problems hiding in one line.

Each row should answer one real question a person or system faces during daily work: approve, reject, ask for review, or wait for more information.

Most teams need the same basic fields: the case itself in simple words, the limits that decide it, any exception that changes the normal path, who approves it, and a short note only when someone might misread the rule.

Limits matter because vague rules create repeat arguments. "Small purchase" means nothing unless you attach a number. "Too old" needs a date range. "Too many requests" needs a count. If risk changes the decision, name the risk level and say who sets it.

Exceptions should sound like normal speech, not legal text. Write "unless the customer already received a replacement" or "except for first-time login from a new country." People can follow that. AI can match it better too.

Approval logic needs the same level of detail. Do not stop at "manager approval required." Say when it is required and who the manager is. If requests over $500 go to finance, put that in the row. If high-risk cases always go to a team lead, say that directly.

Notes help only when they remove doubt. A note like "use order date, not shipping date" saves time. A note that just repeats the rule adds noise.

A simple example makes this easier to picture. Imagine an access request table. One row covers "temporary admin access for production." The limits say it expires after four hours. The exception says security incidents can skip normal timing. The approval column names the on-call lead. That is enough for a person at 2 a.m., and it is clear enough for an AI agent to follow without guessing.

Pick the columns before you fill the rows

Most teams rush to examples. That feels productive, but it creates a messy table fast. Start with the columns. When the columns are clear, people read each row the same way, and AI does too.

Use the words your team already says in calls, tickets, and chat. If support says "refund reason" and finance says "credit category," pick one term and stick to it. The table should feel familiar, not academic.

Start with the few columns that define the rule itself: rule name, condition, action, and status.

Keep status values short and fixed. "Open," "approved," "denied," and "needs review" work better than a long menu of near-duplicates. Once teams add both "pending manager" and "awaiting manager decision," the table stops settling debates and starts creating new ones.

Then add the columns that control exceptions and ownership: exception type, who can approve, effective date, and notes.

Approval logic needs plain limits. Do not write "manager approval" and move on. Name the role and the boundary. "Support lead up to $50" tells people what they can do. "Manager decides" sends the case back into chat, where the same argument starts again.

Effective dates matter more than most teams expect. If your rules change every quarter, or even every month, add start dates and end dates now. That one column can save hours of confusion later, especially when someone checks an old case and asks why the answer changed.

Leave out fields nobody will update. Teams often add columns like "risk score" or "customer sentiment" because they sound useful. If nobody owns them, they go stale fast. Then humans ignore them, and AI guesses around them.

A quick test keeps the table honest. Pull five real cases from last month and fill the table together. If people hesitate on the same column, rename it or remove it. If they reach the same answer with little debate, you are close.

Build the first version step by step

Start with cases that already caused friction. Pull a few weeks of tickets, email threads, and chat messages, then pick the ones that made people pause, escalate, or disagree. Real cases give you facts, edge cases, and the exact wording people use.

Do not try to write a perfect policy from memory. Teams usually remember the clean cases and forget the messy ones. A shared decision table works better when it grows out of work that already happened.

A simple process is enough. Gather 20 to 30 recent decisions and copy the facts into one sheet. Group them by request type, such as refund, access change, discount, or account recovery. For each group, write the normal rule first, meaning the decision you make most of the time. Add exceptions only after two or three real cases show the same pattern. Then test the hard cases with two people and one AI tool and compare the answers.

The order matters. If you add exceptions too early, the table turns into a pile of special cases and nobody trusts it. If you write the common rule first, people can see the baseline and understand why an exception exists.

Keep each row short. One request, one decision, one reason. When approval logic is needed, write who can approve it and what fact triggers the handoff. "Manager approval if refund is over $200" is clear. "Use judgment for larger amounts" invites another argument.

Then run a small test. Give the same five tricky cases to two teammates and the AI tool you plan to use. If all three reach different answers, the rule is still too vague. If the humans agree and the AI drifts, tighten the wording before you automate anything.

This first version does not need to cover every case. It needs to handle the common ones the same way every time. That is how a rule source starts: not as a giant policy document, but as a small set of decisions people can actually follow.

A refund example people can follow

Refunds are where a shared rule source pays off fast. People remember policy in pieces. One agent recalls the dollar cap, another remembers an exception, and the AI assistant guesses from old tickets. That is how one customer gets three different answers.

Take a simple order. Dana asks for a refund on a $34 item nine days after delivery. The table has one row for standard refunds under $50 within 14 days. That row says the agent can approve the refund. The agent follows it, and the AI assistant suggests the same action because it reads the same row.

The next cases change because the row changes, not because a different person handles the ticket.

The damaged-item row should outrank the price limit. If a customer receives a broken $120 item, the team should not block the refund just because someone fixates on the $50 rule. The exception sits in the table, so nobody has to win an argument first.

The same goes for gift cards and late requests. A $20 gift card refund still goes to a support lead. A request on day 21 might still end in a refund, but the manager has to leave a note that explains why. That note turns a fuzzy exception into a documented choice.

This is approval logic in plain English. The bot does not invent policy. The agent does not rely on memory. Both check the same row, follow the same rule, and leave the same audit trail.

If a case matches more than one row, the table should say which rule wins. Without that, people start debating again. With it, Dana gets one answer, the team moves faster, and the next odd refund has a clear place to go.

How the table fits daily work

A shared decision table only helps if people can open it during real work, not after a long search. Put it where support, sales, and ops already spend time. If the rule sits in a forgotten document, people fall back to memory, and memory is usually where arguments start.

That changes a daily habit. Agents should answer from the matching row, not from what they remember, what a coworker said last month, or what feels fair in the moment. A customer asking for the same exception on Tuesday and Thursday should get the same answer both times.

The AI assistant should use that same table before it drafts a reply or suggests an approval path. If the bot sees one set of rules and the team uses another, trust disappears fast. This is where the table stops being a nice idea and starts doing real work.

A simple refund case shows why this matters. Say a buyer asks for a refund on day 12, the order was partly used, and the payment came through a reseller. Without a shared table, support may say yes, sales may push for a credit, and ops may block both because of reseller terms. With one row that covers time limit, usage, channel, exception rule, and approver, the answer gets boring. Boring is good.

New edge cases will still appear. Send them into one review queue instead of letting each team patch the rule on its own. Keep that queue practical: what happened, which row almost fit, why the case was disputed, who made the final call, and whether the table needs a new row or just clearer wording.

Then review disputed cases once a week. That rhythm matters more than a perfect table on day one. A 20-minute review with support, sales, and ops often fixes the same argument that would otherwise waste hours during the week.

If your team wants fewer Slack debates and fewer uneven replies, get this part right. Put the table in the flow of work, train people to use the row, feed the same rule to AI, and treat new exceptions as updates to one shared system.

Mistakes that break trust in the table

Trust drops fast when the table says one thing and daily work says another. After that, people stop checking it. They ask in chat, follow memory, or make the call themselves.

One common mistake is the wording. If the row sounds like legal text instead of a real ticket, support and sales will read it differently. AI will do the same. "Offer goodwill adjustment when reasonable" is vague. "Refund if the order is under 30 days old, under $200, and not marked final sale" is much easier to follow.

Another problem is trying to squeeze too much exception handling into one row. Teams often write one giant rule with five carve-outs, two edge cases, and a note in parentheses. That looks tidy, but it turns every decision into a puzzle. Split messy rows into smaller cases. If a person cannot scan the row in a few seconds, the table is already too dense.

Private copies do quiet damage. Support keeps a spreadsheet. Finance keeps a note in its own folder. A manager saves a screenshot from last quarter. Soon there is no real shared rule source, only competing versions with small differences that matter when money or approvals are involved.

Ownership matters just as much as wording. When nobody owns the table, changes happen without a clear reason, date, or approver. Then approval logic drifts. One team starts allowing manual overrides, another starts blocking them, and both think they follow policy.

AI adds one more failure mode. Teams update the table but forget the documents, prompts, or retrieval source that feed the bot. Then humans use the new rule while AI uses the old one. Imagine the table now requires manager approval above $200, but the bot still reads last month's handbook and approves up to $500. One bad answer like that can undo weeks of cleanup.

A healthy table stays plain, split into clear cases, stored in one place, and owned by one person or team. If debates keep coming back, the table needs work.

Quick checks before rollout

A shared table is not ready because it looks complete. It is ready when people and AI use it the same way under normal pressure. Run a short check on real cases, not made-up edge cases that never happen.

Use a small sample first. Ten to twenty recent cases is enough to expose weak rows, vague wording, and missing approvals.

Give every row one owner. One person updates it, answers questions, and decides when the row needs review. If three people "own" a row, nobody really does.

Name an approver for every exception. Do not write "manager approval" unless one manager role is clearly defined. People need to know exactly who can say yes.

Test row matching with two people. Hand them the same case separately and see whether they choose the same row. If they do not, the table is too fuzzy.

Test the AI on those same cases. The assistant should pick the same row and give the same outcome as the humans. If it needs extra guesswork, the row needs better limits or clearer wording.

Write the change process down. Teams need a simple way to add a row, change a row, and retire a row without side arguments. A short note on version, owner, and effective date is usually enough.

One small habit helps a lot: make people record the row ID they used. That turns debates into a direct check. Instead of arguing from memory, the team can ask, "Which row did you apply?"

If the AI gives the right answer but picks the wrong row, do not wave it through. That still breaks trust. The point is that the answer and the reason come from the same place.

When these checks pass, rollout gets much calmer. Support, ops, finance, and the assistant all pull from the same table, and odd cases go to a named approver instead of bouncing around the company.

What to do next

Do not start with five processes at once. Pick the one that creates the same argument every week: refunds, discounts, access requests, damaged orders, or contract exceptions. That gives you a small test, real volume, and a clear problem to fix.

Build a first draft that covers only the common cases. Keep it plain. One row per situation, one outcome, one owner, and one reason to escalate. A rule table works only when people can scan it in seconds.

Then run that table in real work for two weeks. Ask the team to follow it, and ask managers to note every override. Overrides are useful. They show where the rule is vague, too strict, or missing a real exception.

During those two weeks, watch for three things: which rows people skip or argue about, which exceptions happen often enough to deserve their own row, and which cases still land on a manager even though the answer is routine.

After that, edit the table with one goal: remove repeat judgment. If a manager makes the same call three times, turn that call into a row with a limit and an approval path. If people read one row in two different ways, rewrite it in simpler words.

Suppose three managers approve the same customer credit when a delay passes a set number of days and the amount stays under a cap. That should stop being personal judgment. Put it in the table so the team and the AI use the same rule.

Fix any row that still sends ordinary work uphill. Managers should handle rare cases, not spend time answering the same small question all week.

Clear rules also make automation easier. AI can follow rules that are written down, limited, and approved. If you need help turning a messy workflow into something a small team can actually run, Oleg Sotnikov at oleg.is does this kind of Fractional CTO and AI workflow advisory work in a practical way.