Skip to content

Introduction to DSL (Domain Specific Langauge)

🧠 Philosophy

The DSL is a core part of INTELLITHING’s automation blocks (Triggers). When we first designed triggers, we faced an important user experience decision:

Option 1: Provide endless dropdowns, nested menus, and complex settings (similar to Zapier-style configuration). While flexible, this approach quickly becomes overwhelming, hard to read, and error-prone.

Option 2: Create a human-readable, lightweight language that allows engineers to express logic simply, in a way that’s easy to validate, debug, and extend.

We chose the second path. The result is the INTELLITHING DSL — a concise way to program trigger blocks with natural, declarative rules. Instead of navigating cluttered menus, engineers can now write short, expressive DSL rules that directly capture when something should happen, what should be done, and how results should be emitted.

🔑 Key Concepts

The INTELLITHING DSL is a low-level scripting language for engineers to define event-driven automations. It’s not a general-purpose language — it is intentionally narrow, declarative, and designed to integrate tightly with the INTELLITHING trigger system.

At its core, the DSL lets you express:

  • Event listeners: on <event> bound to a tool's (adapter) supported events.
  • Predicates: if <predicate> conditions that must be satisfied for the rule to fire.
  • Actions: do <action>(...) sequences of tool operations, executed in order.
  • Emissions: emit key=value payloads for downstream workflows or queries.

This event–condition–action–emit structure makes the DSL a compact orchestration layer that is human-readable, machine-validated, and directly executable in the INTELLITHING runtime.

📘 Key Definitions

  • Rule: The full DSL string (on … if … do … emit …) that defines behavior.
  • Event: A trigger from a tool (email_received, slack_message, etc.).
  • Predicate: Boolean condition that determines whether the rule applies.
  • Action: A call to a tool’s capability, with parameters.
  • Emit: A final, structured output (a query) for downstream blocks.
  • Plan: The parsed form of a rule — JSON-like dict used internally.
  • Simulator: Component that previews DSL execution with fabricated outputs (no side effects).
  • Executor: Component that runs actions against real handlers and produces real emissions.
  • Validator: Component that validates the syntex of a given rule.

🧩 DSL at a Glance

One-line Form

on <event> [if <predicate>] do <action>(...) [, <action>(...)] [emit key=value]

Minimal Example

on email_received if not_empty(attachments)
do save_artifacts(dir_template='inbox/{yyyy}-{mm}-{dd}/',
                  filename_template='{subject_slug}-{attachment_name}'),
   set_variable(name='newpath', value_template='{filepath}')
emit query='Saved {newpath}'

This declares:

  • Trigger on incoming email with attachments.
  • Save artifacts with a templated path and filename.
  • Store the resulting file path in a new variable.
  • Emit a final query summarizing the operation.

⚙️ How the DSL Fits into INTELLITHING

The DSL is the lowest-level contract between triggers, tools, and workflows. It sits underneath higher-level abstractions like the Block Editor and Workflow UI.

  • Parsing & Validation ensure rules are syntactically correct and capability-aware.
  • Simulation lets engineers test rules without side effects, seeding plausible values.
  • Execution connects rules to real adapter handlers and produces runtime emissions.
  • Integration with the Router Engine and TriggersWorkflow allows DSL rules to plug seamlessly into the wider INTELLITHING automation architecture.

The DSL makes automation predictable, debuggable, and extensible — enabling engineers to define precise logic, but always within the boundaries of tool-aware validation and structured execution.