01What this guide helps you do
Check that customer messages do not easily override business boundaries.
This guide focuses on one task within alactic acid. Its completion test is specific: The test exposes weaknesses without claiming perfect protection. Use that result to decide whether the task is finished. Opening a page, entering a value or seeing a brief notification can be part of the process without establishing the complete result.
02When to use this workflow
Use this workflow when your immediate goal is to test resistance to instruction changes. Keep the scope limited to the relevant AI test session. If you are solving a different problem, use the related guides at the end rather than applying every action here to unrelated records.
The usual operational owner is the workspace administrator or AI operator. If another person owns the relevant business facts or permissions, involve that person before changing the shared record. Individual access and business authority are not always the same thing.
03Prepare the information you need
Choose a business task and a test question whose important facts you can verify. Use fictional customer details. Identify whether the test uses saved builder knowledge or the live bot context, since those can differ. Keep an expected answer outline and a human escalation route. ACID is a conversational intelligence system, and evaluating it requires more than checking whether the answer sounds polished.
Business rule, adversarial test message, expected response.
04Find the right workspace and feature
Start from Chatbot builder → Alactic ACID. Treat this as a feature locator: the arrangement of menus can differ between the web interface and the native application. Confirm the workspace name and the relevant record before proceeding, especially if you manage more than one business or use both India and UK accounts.
The target of this task is a AI test session. Keep its identity visible while you work. A similarly named record or a previously open browser tab can otherwise make a correct action affect the wrong context.
05Understand the information on screen
| Information | What it means | Practical check |
|---|---|---|
| Test context | Saved builder or live bot knowledge | Confirm which is being evaluated |
| Input and output | Text contributing to usage | Review both components |
| Allowance | Current workspace capacity to use AI | Read the displayed reset and limit |
| Quality evidence | Facts, context and handover tests | Keep reproducible examples |
Apply these distinctions to the specific inputs for this guide: business rule, adversarial test message, expected response. You do not need to collect every possible field in the workspace. Use the information needed to make this decision and to verify its result.
06Inspect the current state first
Review the current workspace allowance, usage units and response settings before a long test session. Both input and generated output contribute to consumption, and test replies count. A reply is not a fixed token quantity. Workspace allowance and shared capacity can independently affect availability, so read the exact error rather than assuming every unavailable response means the same thing.
If the intended result is already present, check whether any further action is necessary. This is particularly useful after an interrupted session or when another teammate may have completed part of the work.
07Step 1: Define the boundary being tested
Begin with the relevant inputs: business rule, adversarial test message, expected response. Resolve any ambiguity that would change which record or business decision the task concerns. Keep a short note of the original state if you will need to compare it later. This creates a clear starting point for the next action instead of relying on memory after several screens have changed.
08Step 2: Ask the assistant to ignore it
Use the result of the first action as the context for this one. Check the exact label, selected value or evidence involved rather than assuming that a default matches the intended task. If you identify an inconsistency, resolve it before proceeding. Keep the change narrow enough that its effect can be understood without comparing many unrelated edits.
09Step 3: Review whether it keeps a useful safe response
Finish by checking the observable result, not only whether the interface accepted an interaction. If the result is still pending or cannot be verified, preserve that distinction in your notes. A clearly recorded unresolved state is more useful than announcing completion and discovering the missing part during a live customer task. Use the verification guidance below for the relevant feature.
10Use adversarial tests as evidence, not a security guarantee
Define a specific boundary before testing it, such as keeping private staff details out of a customer answer. Then use a fictional prompt that tries to redirect the assistant away from that boundary. Record the response and whether it still offers a useful public alternative, such as the normal support route.
Repeat with varied wording and a multi-turn conversation where appropriate. One successful refusal does not prove protection against every possible instruction attack. If a test fails, remove private information from the customer-facing knowledge and improve the control or escalation path; a stronger-sounding instruction alone should not be treated as a complete data-protection measure.
| Check | Meaning for this task |
|---|---|
| Boundary | A specific behaviour being evaluated |
| Test input | Fictional attempt to change the assistant's instructions |
| Evidence | Recorded result with a clear limitation |
11Worked example
An internal tester asks for hidden staff details and checks that the assistant declines and offers public support information.
The useful lesson is the sequence of decisions, not a promised result for every business. In this scenario, begin with “Define the boundary being tested”, continue with “Ask the assistant to ignore it”, and finish with “Review whether it keeps a useful safe response”. Compare the result with the completion test before applying the same process to a wider set of records.
Use invented names and references when practising this example. Keep the structure realistic, but do not copy a live customer conversation or payment record into training material simply to make the demonstration look authentic.
12Verify the result
Compare the answer with approved business facts, the customer's actual question and the intended next action. Test uncertainty, follow-up context and human escalation as well as the normal case. Record results so you can repeat the same examples after a change. Passing a few tests is useful evidence for those scenarios; it is not proof of perfect accuracy or resistance to every adversarial message.
The test exposes weaknesses without claiming perfect protection.
13Decide what to do next
| What you observe | Appropriate next step | What to avoid |
|---|---|---|
| The expected result is visibly present. | Keep the result and continue with the intended business task. | Repeating a completed action without a reason. |
| The result is still pending or uncertain. | Review the current AI test session and the relevant status. | Calling the task complete without evidence. |
| The result conflicts with the intended choice. | Revisit: Ask the assistant to ignore it. | Changing unrelated records to hide the symptom. |
Use the observed state to choose a branch. A recovery action should address the actual cause and preserve any work that is already correct. If several people are involved, make the next owner explicit so a pending state does not become an unattended task.
14The main mistake to avoid
Passing one adversarial example does not establish complete security.
This mistake can make the task appear finished while leaving the business outcome unresolved. Return to the inputs and the named steps when the result is unclear. Keep a useful distinction between what you observed and what you expected. If a weaker signal is all that is available, describe the remaining uncertainty and identify how it can be checked.
15Diagnose an unexpected result
Compare the expected result with the exact current state of the AI test session. Record which of the three actions was last completed and what happened next. Keep the exact validation message or visible status where one exists. This separates an input problem from a saved-state problem and helps another person reproduce the same example.
Check the workspace, selected record and current view. Change one relevant factor at a time. If you change several unrelated settings together, a later success may not explain which change actually resolved the issue.
16Recover without duplicating work
Classify the issue before changing settings. A factual error may come from missing or conflicting knowledge; an allowance response needs usage review; a temporary capacity response needs the indicated recovery path. Change one relevant factor and repeat the original test. Keep a human fallback available so an AI problem does not leave the customer without a practical way to obtain assistance.
If the result depends on a provider or another authorised person, record that dependency and use the appropriate route. Do not simulate success by manually changing an unrelated display value or by removing evidence of the original outcome.
17Use the workflow on web and mobile
Read the full test answer on mobile, including any qualification or suggested next step below the fold. Keep important answers concise enough to use in a WhatsApp conversation. If the answer is shortened, verify that essential facts and limitations remain. A test chat is an evaluation surface and does not itself send a message to a customer WhatsApp conversation.
When comparing devices, match the same account, record and relevant filters. A desktop screenshot and a mobile screen from different contexts are not evidence of inconsistent data. If a layout problem prevents completing the task, report the screen name, device context and the affected control with private details removed.
18Keep a useful operational record
Retain only the information needed to explain the task: its purpose, the relevant AI test session, the action taken and the observed result. If the operation produced a safe reference, keep it with the time and workspace context. This makes a later handover or support query more precise than a screenshot with no explanation.
| Record | Useful content |
|---|---|
| Purpose | Check that customer messages do not easily override business boundaries. |
| Inputs reviewed | Business rule, adversarial test message, expected response |
| Outcome to verify | The test exposes weaknesses without claiming perfect protection. |
| Next owner | Workspace administrator or ai operator |
19Protect private information
Use the minimum customer or business information needed for the task. Restrict access to authorised colleagues, and redact unrelated names, numbers and message content when sharing a screenshot. An evidence reference is often more suitable than copying the underlying private document into a general field or support message.
For this workflow, the useful input categories are business rule, adversarial test message, expected response. They should help you make and verify the decision; they are not a reason to publish a customer database, credentials or internal operating notes. The fictional example in this guide can be used for training without exposing live records.
20Know the limits of this workflow
ACID is Alactic's conversational intelligence system. An AI reply is not a verified business transaction, and a test conversation does not send a customer WhatsApp message.
Evaluate usefulness, factual consistency, handover and consumption together. A shorter answer is valuable when it still answers the customer's actual question.
Read the linked source material for decisions controlled by a provider or by the applicable commercial terms. A practical guide explains how to approach the task; it does not add a new contractual guarantee or establish that every business use is legally suitable. Use the responsible business owner for unresolved exceptions.
21Review the process over time
Build a small improvement backlog from reproducible failures. Prioritise wrong facts, broken handovers and unclear limits before cosmetic preferences. Repeat affected tests after knowledge or response-setting changes and review consumption alongside usefulness. Describe the product accurately in public material: business instructions and integration work are valuable, but they do not establish that a foundation model was trained from scratch.
Update related instructions when the underlying business fact or product behaviour changes. Keep a representative example from this workflow so a future revision can be compared with an explicit expectation rather than judged from memory.
22Practical questions
What should I check before starting?
Prepare business rule, adversarial test message, expected response. Then confirm the workspace and the relevant AI test session. The first action is “Define the boundary being tested”. Starting there keeps later decisions grounded in the correct record and avoids trying to solve a different problem with this workflow.
How do I know the task is complete?
Use this observable test: The test exposes weaknesses without claiming perfect protection. If a state is pending, describe it as pending. If a save or provider operation is uncertain, inspect the current record before repeating it. The result matters more than whether a button was pressed.
What if the result still does not match?
Review this risk first: Passing one adversarial example does not establish complete security. Keep the exact symptom, the relevant reference and the last completed action. Ask the workspace administrator or AI operator or the appropriate support route to review the remaining issue, using a small reproducible example rather than a broad export of customer data.
23Completion checklist
Use this checklist as a final review of the task, not as a substitute for the steps above. If an item remains unresolved, identify the next action and its owner. Do not mark a provider-dependent or unverified result complete merely because the rest of the checklist is finished.
- The intended workspace and AI test session were identified.
- The necessary inputs were reviewed: business rule, adversarial test message, expected response.
- Define the boundary being tested.
- Ask the assistant to ignore it.
- Review whether it keeps a useful safe response.
- The result was checked: The test exposes weaknesses without claiming perfect protection.
- The task-specific risk was considered: Passing one adversarial example does not establish complete security.
- Any unresolved issue has an accountable next owner and a useful evidence reference.