Skip to main content

Documentation Index

Fetch the complete documentation index at: https://setup.cevro.ai/llms.txt

Use this file to discover all available pages before exploring further.

The way you write AIP instructions directly impacts how Cevro handles conversations. Clear, explicit instructions lead to consistent behavior. Vague instructions lead to inconsistent results.

​
Be Explicit About Data

Don’t assume Cevro knows what values mean. Spell it out: Vague: 
Check if the withdrawal is pending.
Explicit: 
Check @withdrawalStatus.

Look for withdrawals where status is "pending" or "processing".

If found:
- Share the withdrawal amount and request date
- Explain: pending = submitted, processing = being reviewed

​
Include Decision Branches

Real conversations branch. Your instructions should too: 
If player provides a transaction ID:
- Look up that specific transaction
- Provide detailed status

If no transaction ID:
- List recent withdrawals from @recentTransactions
- Ask which one they mean

​
Define When to Escalate

Don’t leave escalation to chance. Be specific: 
Escalate if:
- Withdrawal has been pending more than 7 days
- Player reports a discrepancy between their records and system data
- Request requires manual override or exception

​
Use Separators for Sections

When instructions get long, use --- to separate distinct sections: 
Check @playerBalance for available funds.

---

If sufficient:
- Confirm withdrawal is possible
- Explain processing time

---

If insufficient:
- Explain the shortfall
- Suggest deposit options

​
Provide Examples for Ambiguous Cases

When a concept could be misinterpreted, show an example: 
When checking the player's bonus balance, reference bonus_balance, not wallet_balance.

Example:
wallet_balance: 100
bonus_balance: 0
Result: Player has 0 bonus balance (wallet balance is separate)

​
Mark Critical Instructions

Use “IMPORTANT:” to highlight must-follow rules: 
IMPORTANT: Never share account balance information before verifying the player's identity.

Check @playerBalance after authentication completes.

​
Structure Rules as Numbered Steps

When you need the AI to follow a specific sequence — such as a greeting format, a verification flow, or a multi-step process — use numbered steps instead of prose paragraphs. The AI follows structured instructions more reliably. Prose (less reliable): 
The response should start with a greeting and then acknowledge the player's
issue before proceeding to troubleshooting steps.
Numbered (more reliable): 
Every response must start with:
1. Greeting line — on its own line. Never skip this step.
2. Acknowledgment — briefly acknowledge the player's issue. Never skip this step.
Then proceed to troubleshooting.

​
Use “Never” Constraints

Telling the AI what not to do is often more effective than telling it what to do. “Never skip this step” is followed more reliably than “always include this step.” Soft (the AI sometimes ignores it): 
The response must always include an empathy statement.
Explicit (the AI follows it consistently): 
Include an empathy statement. Never skip this — even when the solution is simple.
Never jump directly into instructions without acknowledging the player first.
The pattern: state the rule, then state the failure mode you want to prevent. When the AI knows what the wrong behavior looks like, it avoids it.

​
Put the Common Case First

When writing conditional instructions, lead with the scenario that happens most often. If the special case comes first and its condition is not met, the AI may skip the entire rule — including the default. Conditional-first (unreliable): 
If the player provided their username, address them by name.
Otherwise, use a general greeting.
Default-first (reliable): 
Use a general greeting. If the player's name is known, address them by name instead.
This is especially important for formatting rules that depend on data availability. When the AI encounters a condition it cannot satisfy, it tends to skip the entire instruction rather than falling through to the default.

​
Writing the Description

The description is the single most important field on an AIP. It’s what Cevro reads to decide which AIP to use for a given player message — and if the description is vague or overlaps with another AIP’s description, Cevro may pick the wrong one. Workflow text doesn’t help when the wrong AIP gets picked: the procedure for the right AIP never even runs. A good description has three parts:

​
1. What the player is asking — in their language

Lead with what the player is asking or experiencing, in active voice, in the words a player would actually use. Vague: 
Bonus questions
Better: 
Player asking why their bonus balance is locked or not withdrawable.
The first one is a folder name. The second is a specific player situation Cevro can match a real message against. When your workspace has multiple AIPs covering related topics — e.g., “withdrawal status” and “withdrawal cancellation,” or “missing deposit” and “missing bonus” — be explicit about which scenarios this AIP does not handle. Without exclusions: 
Player asking about a missing deposit.
With exclusions: 
Player reporting a deposit not received or delayed after completing
a payment. Do not use if the deposit was already credited successfully,
and do not use for bonus-related issues.
The exclusion clause is the highest-leverage way to prevent misrouting between similar AIPs. If your workspace has only one AIP in a topic area, exclusions are optional.

​
3. State or timing boundary — when relevant

If two AIPs cover the same topic at different points in a flow (e.g., a withdrawal that’s still pending vs. one that’s already approved), name the player’s state in the description. 
Player asking about a withdrawal that is still pending or processing.
Use only when the withdrawal is not yet completed or sent.

​
Length

25-45 words is the sweet spot. Below 15 words usually means the description is too vague to disambiguate. Above 60 words usually means you’re putting instructions in the description field — that content belongs in the Instructions field instead.

​
Anti-patterns

These are description shapes that look reasonable but break Cevro’s classification in practice:
  • Category names dressed as descriptions — “Bonus questions,” “Verification stuff.” Folder labels, not routing targets.
  • Identical descriptions on two AIPs — if two AIPs have descriptions that match the same player message, Cevro can’t pick correctly. Pick one or differentiate them.
  • Description used as a data store — calendar dates, schedule notes, links. The description is meant to describe player intent; nothing in it can be acted on as data.
  • Catch-all expansions — “…or any issues with X in general.” This destroys scope and makes the AIP overlap every sibling.
  • Operator framing — “When the customer was asking…” or “AIP handles…” Use active player-state voice instead: “Player is asking…” or “Player who has…”

​
Sibling check

Before publishing, read your new description back-to-back with the descriptions of other AIPs in the same topic area. If you can’t articulate which player message each one would match — neither can Cevro. Refine before publishing.

​
Pick the Right Shape for the AIP

Different AIPs need different scaffolding. Reach for the lightest shape that holds.

​
Plain numbered procedure (the default)

Most AIPs are top-to-bottom procedures with light branching. Use a numbered list at the top level, sub-bullets for sub-conditions: 
1. Confirm the issue and acknowledge empathetically.
2. Ask if the player has cleared cache and cookies. Wait for response.
3. If the issue persists:
   - Ask them to try Chrome
   - Disable VPN / Proxy
4. Once details are collected, escalate using @escalate_to_live_agent.

​
Multi-phase procedure

When each step is a substantial named phase (context gathering, verification, decision), use named headers with em-dash titles: 
STEP 1 — VIP TAG CHECK

Call @profile and check data.tags.

STEP 2 — DEPOSIT LOOKUP

1. Check @deposits for any deposit marked "Pending".
2. ...

​
Scenario blocks

When the player can be in one of several mutually-exclusive states (active bonus / completed bonus / cancelled bonus), use scenario blocks instead of a long IF chain: 
Scenario A — Bonus Active
Conditions: status = Active AND "to wager" > 0
Action: Explain the remaining wagering requirement.

Scenario B — Bonus Completed
Conditions: "to wager" = 0 AND status = Converted
Action: Explain wagering is finished, winnings converted.

​
Rules preamble

For tone-of-voice or compliance-critical AIPs, lead with a Rules block of universal caveats that hold across every branch: 
Rules:
- NEVER tell the player there is a "technical issue on our side."
- ALWAYS frame contradictions as "I've flagged this for our team to review."

1. Check the @dashboard->comments for system flags.
2. ...

​
Don’t

  • Don’t use ## NUMBERED HEADINGS in instructions — plain numbered lists work better.
  • Don’t put example player phrasings inside instructions — they belong in the AIP’s exampleUtterances field.
  • Don’t run numbered steps together — every step needs its own line. 5.If a comment says... immediately after 4.If a system... is unparseable.

​
Test and Iterate

  1. Save your AIP (draft mode)
  2. Test in the Preview widget or Playground
  3. Review how Cevro interprets your instructions
  4. Refine based on actual behavior
If results don’t match expectations, the instructions likely need clarification. Cevro follows instructions literally—if something’s not working, make it more explicit.