Behavior Intelligence
Averment provides built-in safety from the start. Behavior Intelligence lets you customize what happens next.
It gives you full control over how your system makes decisions. You can add your own rules, expertise, and domain knowledge, so the system understands what matters most in your specific use case.
Instead of relying only on Averment's built-in logic, you can teach it your requirements and priorities. The system will then use that knowledge every time it evaluates a situation and makes a decision.
What it does
By default, Averment uses built-in intelligence that works across many use cases. Behavior Intelligence lets you add your own logic without writing code.
There are three ways to do it:
- Risk Tolerance: Set how sensitive the system is to risk signals in your context
- Semantic Overrides: Add your own domain-specific signals that the engine uses during evaluation
- Enforcement Rules: Define conditions that directly control the outcome of a decision
All configuration is done from the Averment Console under Controls → Behavior.
Risk Tolerance
Risk tolerance controls how the system classifies actions as low, medium, high, or critical risk. It determines how "cautious" or "relaxed" the system is.
Modes
| Mode | Behavior |
|---|---|
| Strict | Lower thresholds that flags risk earlier |
| balanced | Default which is moderate sensitivity |
| Relaxed | Higher thresholds that allows more before escalating |
The mode defines the default risk thresholds. You can also customize the thresholds for more precise control.
Semantic Overrides
Semantic overrides add custom risk signals during evaluation. They are triggered when specific conditions are met and adjust how risk is scored.
Structure
Each override has:
| Field | Required | Description |
|---|---|---|
| when | Yes | Condition (PolicyNode) that activates the override |
| category | Yes* | Which reasoning category it applies to |
| effect | No | increase (default) or decrease risk |
| activation | No | Signal strength, 0–1 (default: 0.75) |
| weight | No | Multiplier, 0–5 (default: 1) |
| decision_effect | No | Optional direct enforcement override |
| code | No | Identifier for tracking |
*Either
category or categories (array) must be provided.Current available categories
| Category | What it represents |
|---|---|
| ACTION | The type of action being performed |
| VALUE_MOVEMENT | Money or value being transferred |
| TIME_PRESSURE | Urgency or time-sensitive operations |
| IDENTITY_RISK | Identity-related concerns |
| COUNTERPARTY_UNCERTAINTY | Unknown or unverified recipients |
| TRUST_DEFICIT | Low trust signals |
| ACCESS_CONTROL | Permission and access patterns |
| ACCESS_ATTEMPT | Authentication or login attempts |
| PROTECTED_RESOURCE | Sensitive data or resources |
| AUTH_CONTEXT | Authentication state |
| DATA_DESTRUCTION | Destructive data operations |
| PRODUCTION_CONTEXT | Production environment signals |
| BULK_SCOPE | Large-scale or bulk operations |
Example
A fintech company that considers all new beneficiary transactions high-risk:
json
An override that reduces risk for internal transfers:
json
Enforcement Rules
Enforcement rules directly control what happens when their conditions are met. Unlike semantic overrides, they do not adjust risk scores and instead apply a decision immediately.
Structure
| Field | Required | Description |
|---|---|---|
| when | Yes | Condition (PolicyNode) that activates the rule |
| decision_effect | Yes | Action to enforce |
| priority | No | -1000 to 1000, higher runs first (default: 0) |
| code | No | Identifier for tracking |
Decision effects
| Effect | Behavior |
|---|---|
| allow | Let the action through |
| caution | Proceed with awareness; soft gate |
| review | Pause and require active attention |
| block | Stop the action |
| escalate_one_level | Increase severity by one step |
| deescalate_one_level | Decrease severity by one step |
Level Actions
You can also map each pressure level to a specific enforcement action. This overrides the default behavior system-wide for your project.
| Level | Default behavior | Your override |
|---|---|---|
| low | allow | Any action |
| medium | caution | Any action |
| high | review | Any action |
| critical | block | Any action |
Example
Block all actions when a behavior lockdown is active:
json
Limits
| Resource | Maximum |
|---|---|
| Semantic overrides per project | 100 |
| Enforcement rules per project | 100 |
When to use Behavior Intelligence vs Rules
| Use case | Use |
|---|---|
| Domain-specific risk sensitivity | Behavior Intelligence (risk tolerance) |
| Inject risk signals based on conditions | Behavior Intelligence (semantic overrides) |
| Override enforcement for specific patterns | Behavior Intelligence (enforcement rules) |
| Business rules with complex conditions | Rules |
| Rules that need weight-based scoring | Rules |
Both work together. Behavior Intelligence shapes the risk landscape and rules apply business logic on top.
Next steps
Now that you understand Behavior Intelligence, learn how to define Rules that encode your business logic and compliance requirements.
Rules
Define rules that control what is allowed, restricted, or blocked with full support for conditions, effects, and enforcement actions.