Signal Analysis

Name: Lexega
Author: Lexega

Signal Analysis runs pre-execution checks on SQL to surface risks and governance issues (without connecting to Snowflake unless you opt into catalog pulling).

What You Get

A risk report (what was detected) via lexega-sql analyze.
Optional policy enforcement (allow/warn/block) via --policy + --env + --decision-out.

Lexega ships with hundreds of built-in rules (the exact set depends on your installed version). Rather than duplicating them here, the recommended workflow is: discover what's available from the CLI so docs never drift. For a browsable list, see Builtin Rule Reference.

Dialect Coverage

Dialect	Coverage	Signal Categories
Snowflake	Extensive	Security, governance, performance, correctness, semantics
PostgreSQL	Extensive	Security (RLS, roles, privileges), DDL governance, operations
BigQuery	Core	Data movement, governance, BQML lifecycle/security, external data paths
MSSQL	Extensive	Table hints, dynamic SQL, BULK INSERT, DENY privileges, triggers, identity insert, session options
Databricks	Extensive	Delta operations, Unity Catalog governance, row/column security controls, storage credentials
Redshift	Core	PostgreSQL-derived security & DDL governance, plus datashare cross-account exposure, Spectrum external data, COPY/UNLOAD inline-credential exposure, and distribution/sort/backup attributes
MySQL	Core	DML write/grant governance, dialect-aware operators (backtick identifiers, `\|\|` as logical OR)

All dialects use the same signal architecture and policy engine. Custom rules work across dialects.

Discover Rules and Signals

# Show the custom-rule syntax and available signal paths
lexega-sql analyze --list-signals

# Show which signals were extracted per statement
lexega-sql analyze --explain-signals query.sql

# Full detail mode (includes all statements/signals)
lexega-sql analyze --trace --format json query.sql

Batch analysis? When scanning an entire directory, use --detail to see per-file signal breakdowns instead of just the aggregate summary. See Batch Mode & Per-File Detail.

Diff Signals (Semantic Diff)

In addition to static analysis signals (emitted by lexega-sql analyze), Lexega emits diff signals when you run Semantic Diff — they describe semantic changes between a baseline and a head version of SQL.

Emitted by lexega-sql diff and by unified review workflows that include semantic diff.
Surfaced on the same StatementFacts fact tree via the diff.events path — each event is a tagged union (kind: table_added | join_type_changed | where_removed | …).
Custom rules match diff signals the same way they match static signals: predicate on the diff.events path with an each: quantifier. See Custom Analysis Rules for the predicate DSL.

See: Semantic Diff

Signal Output

Every signal — built-in or custom, static or diff — carries the same shape:

{
  "matched_rule": "GRT-TO-PUBLIC",
  "risk_level": "Critical",
  "message": "Avoid granting privileges to PUBLIC. …",
  "evidence": [
    { "type": "RuleMatch", "signal_value": "GRT-TO-PUBLIC", "line_number": 1, "column_number": 28, "location": "query.sql:1:28" }
  ]
}

matched_rule is the only rule-level identifier; policy / exception / decision bundles reference rules by this id.
evidence[*] lists the rule matches with their source locations (the matched rule's signal value, line, and column).
Each evidence entry reports line_number / column_number / location pointing back to the originating SQL.