Why SignalQL exists
SignalQL is an open query language for structured evidence retrieval. It is not owned by a single product and is designed for multi-implementation adoption around a shared standard contract between data systems and reasoning layers.
Neutral positioning
- signalql.org describes SignalQL as a portable evidence layer: events, entities, relationships, and temporal change.
- Vendors implement adapters and compilers; the community evolves the specification.
- SQL may remain an execution substrate, but authors write SignalQL for clarity, safety, and deterministic retrieval.
Why not raw SQL?
SQL is universal but too low-level for evidence intent. SQL and dashboards become repetitive and brittle across tools. SignalQL lifts recurring retrieval patterns into a compact language with deterministic contracts and documented result metadata.
Why not only dashboards?
Dashboards are rigid by design: they answer preselected questions with prebuilt charts. Teams constantly ask follow-up questions that were not modeled in advance. As questions change, dashboards require reconfiguration or a SQL handoff.
SignalQL fills that gap with a language built for exploratory retrieval. Analysts and AI tools can express intent directly in a compact, reviewable query format, while deterministic contracts and bounded operators keep outputs reproducible and review-friendly.
Why now?
AI tools need structured, predictable surfaces. A small, explicit grammar beats prose-to-SQL for reviewability and testing. SignalQL pairs human-readable queries with deterministic execution and explainable metadata, while interpretation remains outside the language core.
What Teams Gain
- Product teams can turn follow-up questions into structured queries instead of waiting for every dashboard variation.
- Data teams get a smaller, reviewable surface for AI-assisted retrieval instead of unconstrained prose-to-SQL.
- Engineering and platform teams can keep evidence intent portable instead of encoding every question in vendor-specific logic.
Pilot Without a Migration Cliff
Start with a narrow slice before changing broader workflows:
- Map one dev or staging warehouse slice to the portable data model.
- Try compile-first workflows (first query) and optional Postgres execution (local Postgres).
- Expand only where SignalQL covers your required retrieval questions; everything else stays on existing tools until the spec grows.
Rollback stays simple: stop authoring SignalQL and keep using approved SQL or existing dashboards. The spec does not require adopting a new hosted runtime.
Design Principles
- Lead with user and event semantics, not implementation details.
- Keep SignalQL retrieval-only; perform interpretation in AI/application layers above it.
- Treat the reference compiler as one implementation; others follow the same AST and determinism bounds.
- Prefer examples that match the portable data model documented alongside this guide.