BehaviorDef where you supply the UUID and write the descriptions yourself. The schema is identical to a pre-built behavior — the difference is that you control everything in it.
Required fields
Every custom behavior needs all four required fields:| Field | What to provide |
|---|---|
behavior_uuid | A UUID v4 you generate. This is how Velma identifies the behavior in behavior_detection events. |
name | A short label, ideally under five words. |
short_description | One sentence — the dictionary definition of what you’re detecting. |
detailed_description | The detection criteria. This is what Velma actually reads to evaluate the behavior. |
A minimal custom behavior
Adapting a pre-built behavior
If a pre-built behavior is close to what you need but the detection language doesn’t fit your context, start from its definition and modify it. The critical step is to use a new UUID — this tells Velma to apply your description, not the original.Get the pre-built definition
Call
GET /api/velma-2-streaming/list-presets and find the behavior you want to adapt. Copy the full object.Generate a new UUID
Replace
behavior_uuid with a UUID you generate. This decouples your custom version from the original.Rewrite the descriptions
Update
name, short_description, and detailed_description to match your context. See Best practices for guidance on writing effective criteria.If you include the same behavior UUID as a pre-built behavior, Velma will use the pre-built language — not your modified description. Always use a different UUID for a custom version.
- Pre-built (from list-presets)
- Custom version (scoped to returns context)
Optional fields
| Field | Type | What it does |
|---|---|---|
applies_to_conversation_type_uuids | UUID array | Restricts detection to the specified conversation types. Null or omitted means all types. |
applies_to_participant_role_uuids | UUID array | Restricts detection to speakers assigned those roles. Null or omitted means all roles. |
Storing your configurations
Velma does not offer a server-side endpoint for persisting behavior definitions. Your fullBatchConfig — including all behavior UUIDs and descriptions — must be sent in the first text frame of every new connection. Keep your configurations in your own codebase or config system so you can reproduce them reliably.
Related
- Using behaviors — how to include behaviors in a request
- Best practices — how to write
detailed_descriptioneffectively