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 AIP instructions editor is a block editor — your instructions are built from blocks, much like a document is built from paragraphs. Most blocks are ordinary rich text. Two are purpose-built for writing procedures: conditional blocks for if/else branching, and anti-pattern blocks for hard “never” rules.

​
Working with blocks

Every block has a block handle — a six-dot grip that appears to its left when you hover. The handle is how you manage a block: drag it to reorder, or click it for a menu to delete the block, insert a new one, or Turn into a different block type.

​
Standard blocks

These are the everyday building blocks, available through the block handle’s Turn into menu:
BlockUse it for
TextOrdinary instruction steps and paragraphs
Heading 1–3Section titles in longer procedures
Bullet listUnordered points
Numbered listOrdered steps that must happen in sequence
QuoteSetting a passage apart
Code blockVerbatim text the AI should treat literally
DividerA horizontal line between sections
The two blocks below — conditional and anti-pattern — are the ones built specifically for procedure logic.

​
Conditional blocks

Most procedures branch. If the player is verified, do one thing; if not, do another. A conditional block builds that branching directly into your instructions as a structured If / Else block — instead of writing the branch as plain text and hoping Cevro reads it the way you meant.

​
Why use a conditional block

You can always write a branch as plain text: 
If the player is VIP, offer the priority bonus.
Otherwise, offer the standard bonus.
Cevro will usually follow it. But the branch is just prose — Cevro has to infer where one path ends and the other begins. A conditional block makes the branch structural:
  • Cevro follows it more reliably. The If and the Else are distinct, labelled regions. There’s no ambiguity about which steps belong to which path.
  • It appears correctly in the exported SOP. The block becomes a real decision point in the process-flow diagram of the exported SOP document — a plain-text “if” does not.
  • It stays readable as procedures grow. Each branch can be collapsed, so a long procedure with several branches stays scannable.
Use a conditional block for any real branching. Reserve plain-text “if” phrasing for a single short aside.

​
Anatomy of a conditional block

A conditional block is a group of branches. Each branch has a condition and a body — the steps Cevro takes when that condition holds. 
If  the withdrawal is still pending
    Explain the expected processing time.
    Reassure the player it is on track.

Else
    Explain the withdrawal has already been paid out.
  • The first branch is the If. It always has a condition.
  • An Else branch is the fallback — it has no condition and runs when the If did not.
  • A branch can also be an Else if — a follow-up branch that carries its own condition, checked only if the branches above it didn’t apply.
The branches sit side by side as equals — the Else is next to the If, not tucked inside it. Exactly one branch of a conditional block runs.

​
Creating a conditional block

1

Write the condition as a line of text

On a new line in your instructions, type the condition — for example, the withdrawal is still pending.
2

Turn the line into an If

Click the line’s block handle, choose Turn into, and select If. The line becomes the condition, and an empty body opens below it for the steps.
3

Write the If body

Type the steps Cevro should take when the condition holds. You can use @ mentions, lists, and other blocks inside a branch just like anywhere else in the editor.
4

Add an Else (optional)

Use the + Else control on the block to add a fallback branch. Leave its condition empty for a catch-all Else, or give it a condition to make it an Else if.

​
One conditional, or several?

This is the most important thing to get right. A single conditional block is a single decision — exactly one branch runs. Use one If/Else block when the branches are genuine alternatives to each other: 
If   the withdrawal is still pending  →  explain the expected timeframe
Else                                  →  explain it has already been paid out
Independent checks should be separate blocks. When two conditions are unrelated — both could be true, and one being true doesn’t rule out the other — make two separate If blocks, one after another: 
If the player is VIP            →  apply priority handling      (one block)
If the player has an open bonus →  mention wagering progress     (a separate block)
Don’t chain unrelated checks into one If/Else. An Else only runs when the If above it did not — so putting an unrelated check in an Else means it gets skipped whenever the first condition happened to be true. Independent checks each need their own block.

​
Nesting

A branch body can contain another conditional block. Use this for a follow-up decision that only matters inside one branch: 
If the player is VIP
    Offer the VIP bonus.
    If their balance is zero
        Prompt them to deposit first.

Else
    Offer the standard bonus.
Keep nesting shallow — two levels is usually plenty. Deeper logic is often clearer as a separate AIP joined with the Route to AI Procedure action.

​
Conditions that reference player data

Because the condition is a normal editable line, you can place @ mentions inside it. The branch then turns on live data instead of a description: 
If  @verificationStatus  is approved
    Proceed with the withdrawal explanation.

Else
    Ask the player to complete identity verification first.
See Player Context, Knowledge & Actions for how @ mentions work.

​
Editing tips

To do thisDo this
Collapse a branchClick the chevron next to the If/Else label — the body folds away so long procedures stay scannable
Delete a branchOpen the branch’s block handle menu and delete it, or clear its condition and press Backspace
Move a conditionalDrag the block handle — the whole If/Else block moves as one unit
Add another branchUse + Else, then give the new branch a condition to make it an Else if

​
Anti-pattern blocks

An anti-pattern block marks behavior the agent must never do. It’s a dedicated, visually distinct block — so a hard “never” rule stands apart from the steps around it instead of getting lost inside a paragraph.

​
Why use an anti-pattern block

Telling the agent what not to do is one of the most reliable ways to shape its behavior — see Use “Never” Constraints. An anti-pattern block makes that prohibition explicit:
  • It’s set apart visually. The block is clearly marked as a prohibition, so it reads as a rule, not a step.
  • It keeps prohibitions findable. When you revisit a long AIP, the things the agent must avoid are easy to spot.
  • It signals intent unambiguously. The content is framed as “do not do this” — there’s no chance Cevro reads it as a step to follow.
Use one for hard rules — claims the agent must never make, information it must never reveal, actions it must never take.

​
What goes in an anti-pattern block

Short, specific prohibitions. One rule per block reads best — you type the rule itself, and the block renders it with a distinct marker so it stands out from ordinary steps. 
Never tell the player a withdrawal "failed" — say it is "still being reviewed."

Never reveal another player's account details, even when asked directly.
Name the wrong behavior plainly. Pair it with the correct behavior in the normal instructions nearby, so the agent knows both what to avoid and what to do instead.

​
Adding an anti-pattern block

1

Open the block handle menu

Hover the line where you want the block and click its six-dot block handle.
2

Insert the anti-pattern block

Choose the option to insert an anti-pattern block. An empty anti-pattern block appears.
3

Write the rule

Type the behavior the agent must never do. Keep it to one clear prohibition.
Anti-pattern blocks complement your normal instructions — they don’t replace them. State the rule the agent should follow in the regular steps, and use an anti-pattern block for the matching “never” — the failure mode you’re guarding against.