> ## Documentation Index > Fetch the complete documentation index at: https://ago.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Business rules laboratory > Write internal policies and test which rules apply to a customer request. The business rules prototype helps staff users maintain internal policies and test their applicability. Open **Knowledge → Business rules**. The page appears only once the prototype is enabled for your workspace; contact AGO to turn it on. The top of the page summarizes the directory: active rules, their split by category, saved test cases, and the duration and outcome of your last test. ## Business decisions and response guidance The directory combines four categories: **Business**, **Tone**, **Wording**, and **Format**. Categories are separate from shared tags. Use the category buttons and tag filter together to find, for example, wording rules about refunds. Choose **Every response** for an unconditional rule. Its condition becomes “Always”, and it is included without semantic retrieval or an applicability-model call. Use **Depending on context** for conditions involving a subject, account fact, channel or language; supply those facts in the test context. Required response rules are always examined, even outside the closest retrieval candidates. Contextual applicability remains an AI judgment. Choose **Required** or **Preference**. For response rules, configure exact **Forbidden expressions**, **Required expressions**, or **Maximum characters** when applicable. Surrounding quotation delimiters are removed from configured expressions. Matching ignores case and normalizes Unicode; it does not translate phrases, interpret paraphrases or ignore punctuation. Character limits count Unicode code points, not words or sentences. A required check violation blocks the candidate; preference violations are reported without blocking. ## Import mixed CX feedback Open **Import CX feedback**, paste the feedback and choose **Analyze text**. One text can produce business decisions, tone, wording and format rules. The preview creates nothing. Review categories, scope, source quotes, duplicates and detected conflicts. Choose **Edit proposal** to correct an entry, or exclude it from the import. Choose **Save proposals** to save the selected entries. New rules are inactive unless **Activate new rules after review** was selected for the analysis. Duplicate checking runs again against the current directory. Detected conflicts block the whole import; correct the proposals or existing rules and analyze again. Keep rules referenced by an extracted exception in the same import. Semantic duplicate and conflict detection are AI assessments and require review. Conflict detection compares rules within the same category, against earlier proposals in the batch and the active rules among the closest existing rules (all existing rules when the directory holds 20 rules or fewer, otherwise the 12 closest). Proposals declared as exceptions to each other are not compared. Inactive rules are still considered for duplicate matching. Contradictions across categories are not automatically detected in this prototype. ## Create a rule Choose **New rule**, pick its category, scope and requirement, enter a title, describe **when the rule applies**, and write the **instruction to follow**. Group rules with subject paths such as `Billing / Refunds` and select existing shared tags. Rules use the same tag identifiers, topics and subtopics as conversations and knowledge documents. Manage this vocabulary in [Conversation Labels](https://ago.mintlify.site/features/conversation-labels.md); renaming a tag updates its name across these views. Moving a rule between subjects does not change its conditions. Under **Exact keywords**, list the words that must always bring the rule up, separated by commas, such as a product or partner name. They match whole words, whatever the case, and keywords of the rule's shared tags count too. Avoid common words: at most 10 rules are brought in by keywords for one request. A rule can carry validity dates under **In effect from** and **Until**: outside them it is ignored, so a rule written for a campaign ends on its own. **Version history** at the bottom of a rule shows its earlier versions. ## Work with a large directory In the directory, rules are grouped by subject. With more than 40 rules the subjects start folded, each showing how many rules it holds; open one to list its rules, 25 at a time. A colored dot shows each rule's state: in effect, inactive, expired or scheduled. Narrow the list with the search field, the category buttons, and the filters by subject, shared tag, status and playbook. Choosing a parent topic also includes its subtopics. Sort by title or by most recently modified. To change several rules at once, tick them, or tick a subject to select all the rules it shows. A bar then offers **Activate**, **Deactivate**, **Link a playbook…** (once a playbook exists) and **Delete**. A deleted rule cannot be restored, and exceptions that pointed at it are detached; deactivate a rule instead when you want to keep it. Keywords of a rule's shared tags always count as its exact keywords; tag names and descriptions only help when the selection falls back to the closest rules. Enable **Always evaluate this rule** for a policy that must be examined on every test. Use **This rule takes precedence over…** to declare an exception explicitly. An applicable exception replaces the linked rule; an unresolved exception prevents that rule from being treated as approved. ## Playbooks A rule says whether to act and what to do. A **playbook** describes how: the steps an agent follows to carry out that action, written in plain language. For example, a rule decides that a promotion applies, and its playbook explains which tool to call, with which information, and what to tell the customer. Open the **Playbooks** tab and choose **New playbook**. Give it a name, say when to use it, and write the instructions in the order the agent must follow them. Turn **Active playbook** off to keep a draft. To link a playbook, open a rule (new or existing) and select it in the **Playbooks** section, below the condition and instruction. While no playbook exists, that section offers **Open the Playbooks tab** instead. A rule can use several playbooks, and one playbook can serve several rules. Linked playbooks appear on the rule in the directory, under the action in a decision, and in the rule's explanation, where you can open their instructions. The playbook lists the rules that use it. Deleting a playbook removes it from the rules that use it; the rules are kept. Each saved change creates a new version. Playbooks are not executed by the laboratory, and existing chat and voice channels do not load them yet. ## Test a request In **Laboratory**, enter a customer message. Optionally paste account facts or an API response into **Account context**. Choose **Test rules**, or press Ctrl/⌘ + Enter. To start from a situation you already saved, select it under **Load a saved case**. If you already know what the request is about, select its **Request topics** (shown once shared tags exist). They help only when the selection below falls back to the closest rules: rules sharing those topics, or their subtopics, then come first. One test evaluates the rules once and shows the **Decision** first: * **Decision reached**: the actions to follow, in order. Select the rule name under an action to see why it was selected. * **Information to confirm**: a required rule is waiting for a fact. The questions to answer are listed; add the facts to the account context and test again. * **No applicable rule**: no business rule covers this request, so a rule is probably missing. A holding reply is still drafted: it acknowledges the request without granting, refusing or promising anything. Choose **Create a rule for this case** to add the missing rule; the customer message is copied into its condition as a starting point, and the test runs again once the rule is saved. A rule about another subject is set aside as not selected; it never asks for its own missing facts. For example, a refund rule is not selected when the customer writes about missing emails. * **Incomplete evaluation**: the model could not evaluate a rule. Run the test again. Keep **Also draft the response** on to get a proposed reply with the decision. Turn it off for the fastest rule-only tests. Below the decision, a colored bar shows how the rules split by result. Rules are grouped: selected rules and rules waiting for information first, then overridden rules. Rules that were not selected are folded; open the group to inspect them. Select a rule to read its explanation, quoted evidence and missing facts. Only the rules that were examined are listed. A line below them counts the rules that were not examined and the inactive ones. To check one of them on this case, open **Examine another rule on this case** and search it by title. The decision shows the duration measured for that test, split into retrieval, evaluation and response, and the model used. Select the copy button on the proposed response to copy it. Up to 20 conditional rules are evaluated in full. Beyond that, the directory is narrowed in three steps before any rule is judged in detail: 1. **Exact keywords**: a rule whose keyword appears in the request, or at the start of the account context, is always examined. 2. **Subjects**: the subjects the request is most likely about are chosen. This step applies once more than 150 conditional rules are in effect. 3. **Rules**: the rules the request is most likely to raise are kept, usually a handful. When subjects were chosen, only their rules and the rules sharing words with the request are considered. Mandatory rules and linked exceptions are added to that selection. Above the list, **Subjects explored** shows the subjects that were chosen with their likelihood, and each rule shows the keyword that brought it in or its relevance. A rule filed under the wrong subject may not be examined: keep subjects accurate, and give a rule keywords when a specific word should always bring it up. This selection relies on OpenAI. When your fast AI model comes from another provider, or the selection is unavailable, the 20 rules closest to the request are examined instead, plus the rules brought in by keywords. ## Edit and compare Choose **Edit and retest**, change the conditions or instruction, then **Test draft**. This evaluates your changes without saving them. The laboratory highlights results that changed since the previous test. Choose **Save rule** to update the shared directory. If another administrator has changed that rule, reload it before saving. Existing test results retain the rule version they evaluated and are marked outdated when the directory changes. ## Keep regression cases After evaluating saved rules, choose **Save as test case**. The message, account context and evaluated statuses become the expected results. Unevaluated rules are not treated as rejected. Review these expectations before saving them. In **Saved cases**, choose **Load** to edit a situation or **Replay** to compare its expected results against current rules. Newly applicable rules are also reported as changes. Each case shows whether its last replay was unchanged or changed. Saved cases are shared with administrators in your organization. Choose **Replay all** after changing rules. The summary tells how many cases still give their expected results, and which share of the expected rules were examined at all. A low share means rules are being missed before they are judged: check that the rule is filed under the right subject, give it exact keywords, or reword it so it names the situation more directly. ## Test a response The proposed reply appears in the decision. Violating excerpts are highlighted when the original text can be located, and the reply is marked **Sending blocked** when a required rule is violated. A required rule still waiting for facts, or that could not be evaluated, prevents generation. Generation cannot execute account actions. Under **Check the response**, edit the reply or paste your own, then choose **Check response**. Choose **Generate response** for a new draft. Each check refreshes the decision, the rules and the reply together, so they always describe the same evaluation. Literal checks run automatically. Select **Also verify meaning and tone** to add one model call checking response guidance. The result distinguishes passed, violated, uncertain, unchecked and inapplicable rules. A passed literal check does not confirm semantic compliance. Required semantic violations or uncertainty also block the reply when semantic verification is requested. The preceding response remains available for comparison. Choose **Save this response test** to preserve the reply and reviewed checks. Replaying a response case uses its saved literal or semantic verification mode and reports changes in applicability and compliance. ## Prototype scope The laboratory uses your configured fast AI model. Existing chat and voice channels are not connected to this prototype. No customer operations are executed. Account context is supplied by the caller. AI applicability and semantic assessments require review. The directory holds up to 2,000 rules, and a request evaluates up to 40 conditional rules, including mandatory rules and exceptions. Rules that apply to every response do not count against this limit. If a linked group exceeds that limit, the test reports an error instead of silently omitting its rules. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.