CURRENT CONTRACT EXAMPLES

Where model output enters the app

These examples show the boundary, not a promised verdict. Provider output varies; ScreenerBot validates the response shape, records the decision, and applies deterministic configuration and trading rules.

Filtering: pass or reject

Pass above the threshold

A token survives every deterministic source and the model returns:

{
  "decision": "pass",
  "confidence": 84,
  "reasoning": "...",
  "risk_level": "low",
  "factors": []
}

With min_confidence = 70, the token continues. It is not bought automatically by this result; strategy and entry gates still decide that.

Reject above the threshold

A typed reject at sufficient confidence becomes an LLM-analysis rejection:

{
  "decision": "reject",
  "confidence": 93,
  "reasoning": "...",
  "risk_level": "high",
  "factors": []
}

The rejection history records its reason, provider, and confidence for later review.

No advisory or UNCERTAIN mode

The filtering schema accepts pass or reject. A confidence value below the floor, an unknown decision, malformed JSON, or a provider failure follows fallback_pass. Values are integer percentages such as 84, not fractions such as 0.84.

Trading analysis is optional input

Entry analysis

When entry_analysis_enabled = true, the trader asks the analysis engine for a fresh typed buy, sell, or hold assessment. The normal filter, strategy, position-limit, loss-limit, and force-stop gates remain authoritative.

Exit analysis

When exit_analysis_enabled = true, the exit path can consult a fresh model assessment. It never replaces emergency exits, stop-loss handling, or on-chain execution verification.

Assistant tool call

“Show my open positions”

1. The selected provider returns a native call to get_positions.
2. Agent Control resolves the in-app portfolio policy.
3. The canonical portfolio tool reads the live app and returns structured data.
4. The provider receives that result and writes the final Assistant response.
5. User, tool, and Assistant events are stored in the same local conversation.

The Assistant calls provider clients directly. The request does not pass through token/trading llm_analysis merely because both use an LLM.

Mutating tool call

“Buy this token with 0.1 SOL”

The Assistant can propose buy_token, but the interactive surface confirms mutating tools before execution. Once approved, the canonical trading owner applies normal validation, quote selection, signing, submission, and verification.

A paired MCP connection is different: its own category policy decides whether trading runs, asks, or is hidden. Neither surface receives wallet private-key material.

Minimal configurations

Filtering

[llm]
enabled = true
default_provider = "anthropic"

[llm_analysis]
filtering_enabled = true
min_confidence = 85
fallback_pass = false
auto_blacklist_enabled = false

Assistant

[llm]
enabled = true
default_provider = "groq"

[assistant]
enabled = true
scheduled_tasks_enabled = false

[agent_control]
analysis = "allow"
portfolio = "allow"
trading = "allow"

Add the matching [llm.providers.<name>] block with a current model ID and credential. Provider changes take effect after restarting the app.

Filtering contract

See the full decision and failure rules.

Assistant tools

See the shared registry and confirmation policy.