Skip to main content

Signal Triggers

Signal is the condition category for real-time social and event-driven triggers:

  • X/Twitter Post maps to EQL source: "tweet" semantic matching.
  • Event maps to EQL source: "news" semantic matching.

Use Signal when you care about what was said (semantic meaning), not only market price movement.

Why Agents Use Signal​

  • React when a specific monitored account posts, instead of polling sentiment indirectly.
  • Capture breaking events by meaning (for example ETF approval, exploit, sanctions), not brittle keyword exact-match.
  • Pair Signal triggers with webhook, notify, telegram_bot, or llm actions for immediate handoff.

Selection Policy​

Choose the Signal source by intent:

  • Use tweet (X/Twitter Post) when the trigger is anchored to a specific account/handle.
  • Use news (Event) when the trigger is a world event and is not pinned to a specific account.
  • Prefer tweet/news over llm when the trigger is plausibly expressed in X/Twitter or news content.
  • Use llm as a last resort for world-state questions that are not naturally represented as post/event matching.

Examples:

  • Alert me if @cz_binance posts that Binance Alpha is listing a new token -> tweet
  • Alert me if spot ETH ETF approval happens -> news

Event Semantics​

Signal conditions are event-driven:

  • tweet and news evaluate when relevant mention events arrive.
  • They are not driven by recurring schedule polling intervals.
  • You can still combine Signal conditions with other condition types using AND/OR.

Condition Contracts​

X/Twitter Post (tweet.semantic)​

Arguments:

  • username: string (required)
  • text: string (required)
  • minConfidence: integer in [0,100] (required)

Important behavior:

  • username should be provided without @.
  • At create-time, Auto resolves username to an active monitored account; if unresolved, validation/create fails.
  • Semantic verification passes only when confidence is >= minConfidence.

Default condition form:

{
  "source": "tweet",
  "args": {
    "username": "cz_binance",
    "text": "Binance Alpha is listing a new token",
    "minConfidence": 80
  }
}

Event (news.semantic)​

Arguments:

  • text: string (required)
  • minConfidence: integer in [0,100] (required)

Important behavior:

  • Event matches are evaluated against mentions from news-tagged sources.
  • Semantic verification passes only when confidence is >= minConfidence.

Default condition form:

{
  "source": "news",
  "args": {
    "text": "SEC approves a spot ETH ETF",
    "minConfidence": 80
  }
}

Text Authoring Constraints (High Impact)​

For tweet and news, args.text quality is the biggest determinant of match quality.

  • Keep text atomic: one event/theme per condition.
  • Phrase text as what the post should say/report, not as a monitoring command.
  • Avoid broad umbrella wording in a single condition.
  • For tweet, do not restate account identity in text; username already scopes publisher identity.
  • If intent has alternatives (A or B), split into multiple Signal conditions and combine with OR.
  • If intent requires co-occurrence (A and B), split into multiple Signal conditions and combine with AND.

Design recommendation:

  • Prefer splitting event-driven Signal intents and schedule-driven (cron.every) intents into separate queries for clearer semantics and easier debugging.

Match Description Quality (Good vs Bad)​

For both X/Twitter Post and Event, keep text as a short factual claim.

X/Twitter Post examples:

  • bad: Bearish vibes -> good: Opens a short position on oil
  • bad: Something bullish -> good: Announces a new stake in TSLA
  • bad: Bullish on a coin -> good: Posts that they're bullish on $HYPE and $SOL

Event examples:

  • bad: Market crash -> good: Major DeFi protocol suffers a $200M exploit
  • bad: War conflict -> good: US imposes new sanctions on Russia
  • bad: Big news -> good: SEC approves a spot ETH ETF

Confidence Tuning​

  • Start with minConfidence: 80.
  • Raise to 85-90 to reduce false positives.
  • Lower to 70-75 if you are missing relevant matches and can tolerate more noise.

Validation Notes​

Common errors:

  • minConfidence must be an integer from 0 to 100.
  • tweet username must be non-empty and resolvable to a monitored active account.